Boeing AI Policy Lead Urges Compliance Shift to Product Model

Policy as Product: Building Compliance at AI Speed With Boeing — Ai4

Ai4

Surging AI coding velocity requires compliance teams to abandon reactive enforcement and engineer automated guardrails directly into developer workflows.

AI-assisted summary of Policy as Product: Building Compliance at AI Speed With Boeing — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by Ai4 on August 17, 2026, this presentation features Alexandria de Aranzeta, Data and AI Governance Policy Lead at Boeing. The talk outlines a fundamental shift for compliance organizations facing exponential AI velocity, presenting a phased roadmap and diagnostic questions to transform static policy into an adopted, living product.

## TL;DR Alexandria de Aranzeta argues that unprecedented technical velocity and mounting regulatory activity render traditional, reactive compliance archetypes obsolete. To avoid becoming bottlenecks, policy professionals must transition into proactive builders—such as architects, engineers, and integrators—who embed governance directly into developer workflows. Drawing on the Vitruvian triad of firmness, usefulness, and delight (*firmitas*, *utilitas*, and *venustas*), she explains that while legal firmness is already standard, modern governance succeeds or fails on usability and user experience. She maps this transition across a five-stage product lifecycle—Discover, Prototype, Ship, Iterate, and Scale—providing concrete diagnostic questions to test whether policies achieve genuine operational adoption.

## Atmosphere & style The presentation carries an urgent, incisive, and intellectually refreshing tone that seamlessly bridges classical architectural theory with modern software engineering. De Aranzeta speaks with poised authority and sharp, relatable candor, challenging long-standing bureaucratic habits with direct, grounded diagnostic questions. Watching it feels like a strategic wake-up call, shifting the mood from defensive regulatory anxiety to an empowering, constructive vision where policy creators proudly identify as product builders.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=4s) The exponential surge in AI coding velocity (projected 14 billion annual GitHub commits) combined with a flood of AI regulations (over 150 state bills passed in a single year) renders traditional, slow-moving compliance unsustainable. - [02:12](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=132s) Traditional compliance models rely on six reactive archetypes (Investigator, Arbiter, Interpreter, Enforcer, Advisor, and Domain Expert) that only trigger after an incident, dispute, regulation, or specific inquiry occurs. - [02:12](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=132s) To prevent governance from becoming an organizational bottleneck, compliance must shift upstream from reactive problem solvers to proactive problem definers and system builders. - [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) The modern compliance operating model transforms reactive archetypes into proactive builder roles: Architect, Partner, Engineer, Integrator, Designer, and Researcher. - [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) As technical delivery accelerates and statutory mandates multiply, policy and compliance professionals are positioned to become key product builders within enterprise software ecosystems. - [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) Drawing from Vitruvian architecture, well-crafted governance must balance three core pillars: structural firmness (firmitas), practical usefulness (utilitas), and intuitive user delight (venustas). - [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) Historically, compliance functions have mastered legal firmness (firmitas) while almost completely neglecting operational usefulness and user delight. - [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) Because policy directly engages human users, dynamic workflows, and measurable adoption metrics, it must be developed, launched, and managed as an ongoing product. - [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) Effective policy discovery requires embedding directly within developer workflows to uncover operational ground truth, tested by the diagnostic question: 'Who did you talk to before you wrote it?' - [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) Instead of drafting rigid mandates in secret, compliance teams should release lightweight policy prototypes to skeptical stakeholders to intentionally expose failure points early. - [12:36](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=756s) Publishing and formal executive approval do not equal adoption; treating policy as a product requires go-to-market execution based on audience segmentation, presentation, and workflow integration. - [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) Repeated policy inquiries and user friction should be treated as product telemetry signals indicating broken or ambiguous clauses that require iteration, rather than user resistance. - [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) Scalable governance relies on building automated guardrails directly into developer tooling and existing operational paths rather than maintaining external, standalone textual policies. - [15:05](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=905s) As artificial intelligence turns enterprise roles into builder disciplines, the defining frontier of policy and governance over the next decade will be usefulness and user delight.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=4s) The Velocity of AI and the Legislative Explosion

Alexandria de Aranzeta opens with a sharp observation about the temporal reality of the modern artificial intelligence landscape, grounding her remarks at a precise moment in time: August 5, 2026, at 11:22 a.m. In the fast-evolving world of AI, time is a critical unit of measurement, meaning perspectives and frameworks valid today may become outdated within a month, a week, or certainly a year. Clarifying that her viewpoints are strictly personal and do not represent past or present employers, she draws attention to two staggering metrics that illustrate the current technological inflection point: 14 billion and 150.

The first figure, 14 billion, represents the projected number of GitHub code commits by the end of the year—a dramatic 14-fold increase compared to the roughly one billion commits recorded the prior year. This exponential jump reflects an engineering velocity fueled by autonomous AI coding agents, enabling technical teams to ship software leaner and faster than ever before. Simultaneously, the regulatory landscape is attempting to keep pace: 150 is the number of AI-related bills passed by US state legislatures in the preceding year alone, whittled down from over 1,000 proposed bills, with legislative activity in 2026 already outpacing those benchmarks. This convergence of unprecedented technical velocity and legislative volume demands that organizational policy and compliance functions fundamentally transform to meet the AI moment.

- **14 Billion:** Projected annual GitHub commits, driven by AI agent-assisted development (a 14x year-over-year increase). - **1,000+ Proposed / 150 Passed:** AI-related bills across US states in the previous year, with current-year counts exceeding that pace.

---

[02:12](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=132s) The Traditional Operating Model: Six Responsive Archetypes

For decades, the compliance and policy professions have operated under a highly stable, well-defined paradigm structured across six primary operational dimensions. These roles served organizations effectively when the pace of change was slow, allowing professionals time to read multi-hundred-page statutes, digest regulatory guidance, conduct internal socialization, and audit processes against clear, infrequent benchmarks.

However, each of these classic dimensions suffers from a shared structural vulnerability: they are entirely reactive and rely on external triggers to activate:

- **Investigator:** Triggered by an incident; steps in after a failure occurs to reconstruct facts and determine root causes. - **Arbiter:** Triggered by disputes; serves as a judge or tiebreaker between conflicting teams arguing over applicable rules. - **Interpreter:** Translates complex legal, statutory, and regulatory texts into human-readable organizational guidance. - **Enforcer:** Activated when a line is crossed; determines infractions and metes out punitive consequences after the fact. - **Advisor:** Delivers subject-matter guidance under severe time constraints and with incomplete operational data. - **Domain Expert:** Reads hundreds of pages of rules, synthesizes industry trends, and waits for specific technical questions to arise.

Because every dimension waits for an input—an incident, a dispute, a regulation, or a question—the traditional model cannot scale to the throughput of modern AI development. To avoid becoming bottlenecks, compliance practitioners must shift upstream from being reactive "problem solvers" to proactive "problem definers."

---

[04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) The Future State: From Policy Officers to Product Builders

The future of compliance does not discard core investigative or analytical capabilities; rather, it elevates them into proactive, engineering-aligned builder archetypes. Instead of enforcing mandates after deployment or dispensing advice in isolated silos, compliance professionals must step into active development lifecycles to design guardrails directly into systems.

```mermaid flowchart LR accTitle: Evolution of Policy and Compliance Roles accDescription: Mapping the six traditional reactive compliance archetypes to modern proactive builder archetypes.

subgraph Reactive ["Traditional Reactive Model"] direction TB R1["Domain Expert"] R2["Advisor"] R3["Enforcer"] R4["Interpreter"] R5["Arbiter"] R6["Investigator"] end

subgraph Proactive ["AI-Era Builder Model"] direction TB P1["Architect"] P2["Partner"] P3["Engineer"] P4["Integrator"] P5["Designer"] P6["Researcher"] end

R1 --> P1 R2 --> P2 R3 --> P3 R4 --> P4 R5 --> P5 R6 --> P6 ```

In this transformed operating system, the domain expert becomes an **Architect** who designs the foundational scaffolding for internal controls. The advisor becomes an embedded **Partner** participating early in conceptual phases. Most notably, the enforcer becomes an **Engineer**—shifting the mechanism of compliance from post-hoc punitive consequences to pre-built, automated gates. The interpreter evolves into an **Integrator** connecting rules directly to individual user workflows rather than relying on one-way translations. The arbiter acts as a **Designer**, treating policy exceptions and workarounds as telemetry signals to co-design better systems. Finally, the investigator becomes a **Researcher**, using discovery techniques, user interviews, and fail-point mapping up front.

De Aranzeta stakes a bold futurist claim: over the next several years, "policy and compliance professionals are going to be shipping the best products." As statutory mandates multiply and AI agents accelerate code delivery, well-built governance mechanisms will distinguish leading organizations.

---

[07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) The Vitruvian Triad: Why Policy Is a Product

To establish what it truly means to be a "builder," de Aranzeta journeys back two millennia to the 1st century BCE Roman architect Marcus Vitruvius Pollio and his seminal treatise *De Architectura*. Vitruvius posited that builders cannot merely understand physical masonry; they must be broadly educated in geometry, history, music, law, medicine, astronomy, and the arts so their creations can "stand within a world, not just on a page." This broad polymath requirement mirrors the interdisciplinary foundation required of modern policy builders.

Vitruvius established that any well-built structure must satisfy three indispensable conditions: *Firmitas* (firmness), *Utilitas* (usefulness), and *Venustas* (delight). Applying this classical triad to organizational governance reveals an acute industry imbalance:

| Dimension | Architectural Meaning | Policy Equivalent | Historical Reality | |:--- |:--- |:--- |:--- | | **Firmitas** | Structural strength, durability | Does the policy pass audits, withstand incidents, and satisfy regulators? | **Mastered:** "Firmitas for days." Standard policies are almost always legally sound and rigorously drafted. | | **Utilitas** | Functionality, utility | Is the policy self-serve? Can an engineer reference it on a Friday afternoon to ship safely? | **Inconsistent:** Often opaque, burdensome, or detached from operational realities. | | **Venustas** | Beauty, delight, aesthetic appeal | Does the policy deliver an intuitive, engaging user experience that teams actually want to use? | **Absent:** Rarely, if ever, prioritized in traditional compliance drafting. |

Achieving only one out of three criteria has been the classical definition of poor craftsmanship for 2,000 years. A true builder assumes accountability for how a product functions in the hands of end users. Because policy operates with real users, dynamic user experiences, and measurable adoption rates, it must be designed, delivered, and managed as a product.

---

[10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) The Policy as Product Lifecycle: Discovery and Prototyping

Recognizing policy as a product provides compliance professionals with an established, battle-tested product management roadmap consisting of five iterative phases: **Discover**, **Prototype**, **Ship**, **Iterate**, and **Scale**.

```mermaid flowchart LR accTitle: The Policy as Product Lifecycle accDescription: Five iterative phases of the Policy as Product lifecycle showing feedback loops.

D["1. Discover"] --> P["2. Prototype"] P --> S["3. Ship"] S --> I["4. Iterate"] I --> Sc["5. Scale"] I -. "User Telemetry".-> D ```

Applying this product mindset redefines the first two stages:

- **Phase 1: Discover.** True discovery requires going directly to where developer and operational behaviors occur. Rather than relying on second-hand assumptions, policy authors must uncover the user's ground truth. Drawing from her background in enforcement reviewing hundreds of corporate policies, de Aranzeta notes that compliance failures rarely stem from poor drafting (*firmitas*), but from a lack of practical usefulness (*utilitas*). The essential diagnostic question every author must ask is: *"Who did you talk to before you wrote it?"* - **Phase 2: Prototype.** In classical compliance, policies are treated like formal legal filings—drafted in secret, heavily polished, and unveiled as rigid, finished mandates. In product design, however, early versions are intentionally built to fail rapidly in order to generate learning. Compliance practitioners should draft lightweight iterations, explicitly stamp them as prototypes, and strategically circulate them among the stakeholders expected to push back the hardest.

[12:36](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=756s) Testing Rules and Shipping Policy as a Go-to-Market Product

When testing a policy before launch, drafting a few variations of a specific rule and placing them in front of three distinct teams offers immediate operational clarity. Asking those teams to walk through real use cases against the proposed wording yields ready-made case studies for post-launch implementation, while providing concrete directional feedback for final publication. The essential diagnostic question to pressure-test this phase is straightforward: *"What changed after someone tested?"*

Transitioning from testing to shipping requires re-evaluating the perceived finish line. Traditional organizations often celebrate the moment a policy is formally approved and published, but publication, formal approval, and awareness campaigns do not constitute adoption. Treating policy as a product means applying go-to-market disciplines borrowed from product marketing:

```mermaid flowchart LR accTitle: Policy Go-to-Market Framework subgraph GTM ["Go-to-Market Strategy"] direction TB A["<b>Segmentation</b><br>Prioritize audience & establish touchpoints"] --> B["<b>Presentation</b><br>Target right venue, timing & messaging"] B --> C["<b>Integration</b><br>Embed directly into behavior path & workflow"] end C --> D["<b>Adoption</b><br>Evaluate true adoption rate"] ```

- **Segmentation:** Identifying who to prioritize, how to reach them for the initial engagement, and how to maintain consistent contact thereafter. - **Presentation:** Delivering the message to the right target group at the right time, in the right venue, with precise messaging aligned to a predefined outcome. - **Integration:** Directly plugging policy requirements into existing operational workflows and behavioral paths. - **Diagnostic metric:** *"What is your policy's adoption rate?"*

---

[13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) Iteration Loops and Scaling Compliance as a Co-Builder

Iteration serves as a critical operational feedback loop. When compliance teams begin receiving an influx of inquiries—whether twenty, fifty, one hundred, or two hundred and fifty requests regarding a single clause—that volume is a signal to revisit and refine the language internally. Rather than viewing friction as resistance, builders view repetitive queries as actionable data points. Teams must honestly ask themselves: *"Which policy are you keeping because it works and which one because it was really hard to align? We all know the one."*

At scale, the most effective policies are those that embody *utilitas*—they are actively used. When tools and policies are genuinely usable, they are followed, ensuring that organizational safeguards actually take effect. This dynamic transforms compliance into an active co-builder and co-designer alongside engineering teams. The core operating principle is to build where the work is currently happening and scale tools where the work is heading in the future, prompting the diagnostic inquiry: *"How much of your policy is actually built in?"*

- **Request thresholds:** Tracking support tickets and policy clarification requests (20, 50, 100, 250+) to identify broken or ambiguous clauses. - **Embedded compliance:** Shifting from standalone textual mandates to automated, built-in tooling within developer and operational workflows.

---

[15:05](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=905s) The Vitruvian Builder: Firmitas, Utilitas, and Delight in the AI Era

Connecting the five-phase roadmap, the six dimensions of the compliance professional, and the five diagnostic questions reveals an ancient architectural truth. Over two thousand years ago, the Roman architect Vitruvius established that all good building must satisfy three conditions: firmness (*firmitas*), usefulness (*utilitas*), and delight (*venustas*).

The compliance and legal professions mastered *firmitas* (firmness and rigor) long ago, establishing robust legal guardrails and risk controls. However, artificial intelligence is rapidly transforming every skill set across the enterprise into a building discipline. This technological shift elevates usefulness and delight into the defining frontiers of governance. Policy professionals must embrace their emerging identity not merely as gatekeepers, but as active builders shaping useful, elegant, and resilient systems.

## Notable quotes > What if your policy had an adoption rate? — Alexandria de Aranzeta

> [00:04](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=4s) 14 billion and 150. — Alexandria de Aranzeta

> [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) policy and compliance professionals are going to be shipping the best products. — Alexandria de Aranzeta

> [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) stand within a world, not just on a page. — Alexandria de Aranzeta

> [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) Firmitas for days. — Alexandria de Aranzeta

> [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) Who did you talk to before you wrote it? — Alexandria de Aranzeta

> [12:36](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=756s) What changed after someone tested? — Alexandria de Aranzeta

> [12:36](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=756s) What is your policy's adoption rate? — Alexandria de Aranzeta

> [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) Which policy are you keeping because it works and which one because it was really hard to align? We all know the one. — Alexandria de Aranzeta

> [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) How much of your policy is actually built in? — Alexandria de Aranzeta

## Mentioned Alexandria de Aranzeta, Boeing, Ai4, GitHub, Marcus Vitruvius Pollio, De Architectura

## Video description Alexandria de Aranzeta - Data and AI Governance Policy Lead, Boeing

What if your policy had an adoption rate? Keeping pace with AI demands a shift from a reactive way of working to an entirely different operating system. This talk will trace a phased roadmap for policy to meet the AI moment, the diagnostic questions to pressure-test how policy gets built today, and the one skill that will define the profession's next decade.

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

中文简报

波音AI政策负责人呼吁合规转向产品模式 AI编码速度的飞速提升要求合规团队摒弃被动式执法,将自动化护栏直接构建到开发人员的工作流程中。 Alexandria de Aranzeta 认为,前所未有的技术推进速度以及日益频繁的监管行动使得传统的被动合规原型走向过时。为了避免沦为瓶颈,政策专业人员必须转型为架构师、工程师和集成者等主动构建者,将治理直接嵌入开发者的工作流程中。她借鉴了维特鲁威三要素——坚固、实用与愉悦(*firmitas*、*utilitas* 和 *venustas*),指出尽管法律层面的坚固性已是既定标准,但现代治理的成败取决于可用性与用户体验。她将这一转型贯穿于“发现、原型设计、交付、迭代和扩展”(Discover, Prototype, Ship, Iterate, and Scale)这五个阶段的产品生命周期,并提供了具体的诊断性问题,以检验政策是否在实际运营中真正得到采纳。 随着 AI 编码工具驱动 GitHub 年代码提交量预计激增至 140 亿次(同比增长 14 倍),加之一年内超过 150 项州级 AI 法案通过,传统滞后的被动合规模式已无法应对技术与立法的双重爆发。 (0:04) 传统合规依赖事后触发的六大被动角色,现代体系正将其全面升级为架构师、工程师、设计师等主动构建者角色,将合规防护机制直接前置并内嵌至工程生命周期中。 (4:52) 借鉴维特鲁威建筑三要素(稳固 Firmitas、实用 Utilitas、愉悦 Venustas),合规部门虽早已精通法律层面的稳固性,但在开发者的实际可用性与易用体验上仍长期缺位。 (7:14) “政策即产品”理念通过调研、原型、发布、迭代与扩展五阶段模型推进治理,采用类似 GTM 的产品化运营和遥测指标,推动规则转化为具备真实采用率的高效内部工具。 (10:49)

Reading summary

Alexandria de Aranzeta argues that the accelerating velocity of AI development and rising legislative activity render traditional, reactive compliance obsolete. To keep pace, compliance organizations must treat policy as an engineered product, embedding governance directly into operational workflows rather than relying on post-hoc enforcement. AI Velocity Versus Expanding Legislative Volume (0:04) Modern technical development operates at an unprecedented speed driven by autonomous coding agents. De Aranzeta highlights projections that annual GitHub commits will reach 14 billion by the end of the year—a 14-fold year-over-year surge from roughly one billion commits. This sharp increase in code volume allows engineering teams to ship software faster and leaner, dramatically reducing deployment cycles. Concurrently, regulatory scrutiny is expanding. In the United States, state legislatures introduced over 1,000 AI-related bills in the previous year, enacting 150 into law, with legislative production in 2026 pacing ahead of that rate. Because policy operates in an environment where frameworks rapidly date, de Aranzeta asserts that compliance functions can no longer rely on slow, periodic reviews to govern fast-moving technological output. Shifting Reactive Compliance into Engineering Archetypes (4:52) Traditional governance depends on six reactive archetypes—Investigator, Arbiter, Interpreter, Enforcer, Advisor, and Domain Expert. Each function remains dormant until triggered by an outside event, such as an incident, an internal dispute, a new statute, or a technical inquiry. In an environment dominated by rapid AI deployment, waiting for triggers creates severe operational bottlenecks. To address this lag, de Aranzeta proposes evolving these roles into proactive builder archetypes. The Domain Expert becomes an Architect designing structural controls; the Advisor becomes an embedded Partner early in development; the Interpreter becomes an Integrator linking rules to user workflows; the Arbiter becomes a Designer interpreting rule exceptions as telemetry; and the Investigator becomes an upfront Researcher. Crucially, the Enforcer transitions into an Engineer, replacing retrospective punishment with automated, pre-built guardrails directly integrated into production pipelines. The Vitruvian Triad: Redefining Policy as Product (7:14) Drawing on the 1st century BCE Roman architect Vitruvius's treatise De Architectura, de Aranzeta notes that durable construction requires three core elements: Firmitas (firmness), Utilitas (usefulness), and Venustas (delight). Builders must master diverse disciplines—including law, geometry, and the arts—so their creations function within the real world rather than remaining theoretical designs on paper. Applying this triad reveals an operational imbalance in corporate governance. Compliance departments traditionally master Firmitas by drafting legally unassailable policies that withstand audits and regulatory scrutiny. However, they routinely neglect Utilitas (operational utility and self-service accessibility) and Venustas (intuitive user experience). De Aranzeta maintains that fulfilling only one of the three criteria constitutes poor craftsmanship; because policies have real end-users and measurable adoption patterns, they must be designed and maintained like software products. Operationalizing Governance Through Product Lifecycles (10:49) Treating policy as a product establishes an iterative roadmap across five phases: Discover, Prototype, Ship, Iterate, and Scale. In discovery and prototyping, authors must engage end-users directly and test draft rules with distinct teams to gather empirical feedback, explicitly treating early iterations as testable prototypes rather than immutable legal mandates. For distribution, organizations should adopt product go-to-market strategies—including audience segmentation, targeted messaging, and direct workflow integration—measuring genuine adoption rather than mere publication. During iteration, incoming inquiry volumes (such as 20, 50, 100, or 250+ clarification requests regarding a single clause) serve as telemetry indicating ambiguous or dysfunctional rules. At scale, successful compliance functions operate as co-builders, embedding automated tools directly into existing and future developer workflows. De Aranzeta concludes that as artificial intelligence transforms technical and organizational tasks into building disciplines, compliance professionals are poised to ship critical internal products. The long-term efficacy of governance will depend on whether organizations move beyond legally rigid mandates to design policies centered on practical utility and automated integration.

精炼阅读摘要

Alexandria de Aranzeta 提出,在 AI 编程代理驱动的代码激增与立法爆发的双重冲击下,企业合规职能必须摆脱事后响应的被动定位,全面转向“政策即产品”的工程构建模式。她认为,合规人员应当运用产品生命周期理念与用户体验设计,将治理规则直接内嵌于业务与技术开发工作流之中。 技术增速与监管激增暴露传统合规瓶颈 (0:04) de Aranzeta 指出(说明仅代表个人观点,时间基于 2026 年 8 月 5 日),当前技术与政策正处于急剧变化的交汇点。得益于自主 AI 编程代理的应用,GitHub 全年代码提交量预计达到 140 亿次,较上一年度的约 10 亿次实现 14 倍的爆发式增长;与此同时,美国各州立法机构此前一年提出了超过 1000 项 AI 相关法案,最终通过 150 项,且 2026 年的立法节奏仍在进一步加快。 面对这种技术交付速度与监管体量,传统由六大响应式维度构成的合规模式面临失效。该模式长期依赖外部事件触发:事故发生后调查事实的“调查员”、处理团队冲突的“仲裁员”、翻译法条的“解释者”、违规后实施惩戒的“执法者”、在紧迫时间内提供建议的“顾问”,以及被动等待提问的“领域专家”。这种全流程依赖被动输入的工作机制,在快节奏的 AI 开发周期中极易退化为业务交付的结构性瓶颈。 从响应式职能向工程构建者角色的演进 (4:52) 为避免成为交付瓶颈,合规职能必须前置并升级为工程导向的构建者模型。在该体系中,领域专家演化为设计内部控制底层架构的“架构师”(Architect);顾问转变为在概念设计初期即介入业务的“伙伴”(Partner);执法者演进为“工程师”(Engineer),将事后惩罚替代为预先构建的自动化门禁;解释者升级为直接将规则融入用户工作流的“集成商”(Integrator)。 此外,传统仲裁员升级为“设计师”(Designer),把业务流程中的特例与规避操作视为系统优化迭代的遥测信号;调查员则转变为“研究员”(Researcher),在前期运用用户访谈与故障点映射等发现工具。de Aranzeta 据此做出预测,未来数年内随着法律要求激增与 AI 交付提速,政策与合规专业人员将成为企业内部交付最优秀产品的主体。 维特鲁威三要素揭示合规设计的结构失衡 (7:14) 为阐明政策为何是产品,发言者引用了公元前 1 世纪古罗马建筑师维特鲁威在《建筑十书》中确立的三大核心原则:坚固(Firmitas)、实用(Utilitas)与愉悦(Venustas)。维特鲁威强调建造者必须博览群书,使构筑物立足于真实世界。将这一经典三要素映射至企业治理,暴露出传统合规在设计理念上的严重失调。 传统合规在历史上早已完全掌握了“坚固性”(Firmitas),政策在法理与审计上往往无懈可击;然而,“实用性”(Utilitas)却表现不稳定,规章往往冗长晦涩,无法让工程师在周五下午的安全发布中轻松自助查阅;“愉悦性”(Venustas)即良好的用户体验则几乎完全缺位。两千年来仅满足坚固一项一直被视为拙劣工艺的表征,真正的建造者必须对产品在终端用户手中的实际使用体验与采纳度承担责任。 政策产品生命周期的五阶段落地与迭代 (10:49) 在“政策即产品”的方法论下,合规工作遵循“发现、原型、发布、迭代、规模化”五阶段闭环。在发现阶段,起草者必须深入开发者与一线操作场景,诊断核心在于“动笔前你与谁沟通过”;在原型阶段,政策不应作为定稿秘而不宣,而应制成轻量原型,主动推送给预期阻力最大的利益相关方快速试错,检验“测试后作出了哪些调整”。 发布阶段需引入产品上市(GTM)纪律,涵盖受众细分、精准场景呈现与行为路径内嵌,以实际采纳率而非单纯的签发宣贯作为成功指标。在迭代与规模化阶段,合规团队应把针对单一条款的海量咨询(如达到 20、50、100 或 250 次以上)视为规则表述存在缺陷的遥测数据加以优化。最终目标是将文本政策直接转化为研发流程中的内置自动化工具,在工作发生的源头实现规模化合规。 de Aranzeta 总结认为,随着生成式技术促使企业各项职能向工程构建化转型,合规治理的护城河正在由合规法理的“坚固性”拓展至工具体验的“实用性”与“愉悦性”。但这也给传统合规体系提出了未解决的现实课题:如何在保持法律严谨性的同时,克服法务与工程文化差异,将抽象条文精准转化为无缝内嵌的软件逻辑。

Detailed notes — zh

## Background 本内容由 Ai4 频道于 2026 年 8 月 17 日发布在 YouTube 平台。视频由波音(Boeing)数据与 AI 治理政策主管 Alexandria de Aranzeta 主讲,主题为《政策即产品:与波音共建 AI 速度下的合规体系》,探讨如何摆脱被动响应模式、以产品思维重塑 AI 时代的合规与政策制定体系。 ## TL;DR 面对 AI Agent 驱动的代码交付激增与密集出台的监管法案,传统的响应式合规体系已无法适应当前节奏。演讲提出将合规专业人员从被动的“问题解决者”重塑为主动的“构建者”,完成从领域专家、执法者到架构师、工程师等角色的升级。借鉴维特鲁威建筑三原则(坚固、实用、愉悦),治理团队需将“政策即产品(Policy as Product)”贯穿于发现、原型、交付、迭代和规模化全生命周期,通过 GTM 策略与工程协同将合规要求原生内置于工具链与业务流中。 ## Atmosphere & style 整场演讲节奏紧凑、干练有力,讲者以精确到分钟的时间切片幽默开场,迅速营造出 AI 时代时不我待的紧迫感。叙事逻辑严密且极具说服力,既有古典建筑哲学的深厚隐喻,又有直击企业合规痛点的犀利诊断。整体氛围兼具前瞻战略视野与硬核工程务实感,传递出一种鼓励政策人员跨界成为“产品构建者”的振奋力量。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=4s) AI 时代工程交付速度呈指数级暴增(预计 GitHub 年代码提交量达 140 亿次),叠加州级立法激增,对传统合规模式带来严峻考验。 - [02:12](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=132s) 传统合规扮演的六大角色(调查员、仲裁者、解释者、执法者、顾问、领域专家)存在致命共性:全部属于被动等待输入的响应式(Responsive)模式。 - [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) 合规专业人员需要向“构建者(Builder)”范式升级,从被动的问题解决者转变为主动的问题定义者与系统架构师。 - [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) 执法职能最关键的跃迁在于放弃“事后惩戒”,转向“以工程师思维直接构建代码级或流程级的防护门禁”。 - [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) 借鉴古罗马建筑师维特鲁威的三原则(坚固 Firmitas、实用 Utilitas、愉悦 Venustas),传统政策往往只做到了“坚固”,却缺乏“实用”与“愉悦”。 - [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) 提出“政策即产品(Policy as Product)”理念,强调政策拥有真实的用户、体验以及客观存在的采纳率(Adoption Rate)。 - [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) 政策产品化工作流包含五个阶段:发现(Discover)、原型(Prototype)、交付(Ship)、迭代(Iterate)与规模化(Scale)。 - [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) 原型阶段应抛弃“官方定稿”心态,快速起草初版并策略性分发给反弹最大的业务团队进行压力测试与用例检验。 - [13:02](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=782s) 发布、审批或宣贯不等于采纳,政策需要引入 GTM 策略,聚焦受众细分(Segmentation)、场景呈现(Presentation)与流程嵌入(Integration)。 - [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) 持续迭代要求将业务咨询与豁免申请视作高价值“数据点”,当触发频次阈值时及时重构卡点条款。 - [14:26](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=866s) 政策规模化的最高形态是合规内生于工具链,合规人员作为共建者与工程团队协同,将政策以代码和工具的形式内置于系统。 - [15:05](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=905s) AI 时代正在将合规转化为一门“构建学科”,在保持坚固耐用的同时,规模化实现政策的实用性与愉悦感是未来核心课题。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=4s) AI 时代的速度与合规挑战 在 2026 年 8 月 5 日上午 11 点 22 分这个具体的时间节点,Alexandria de Aranzeta 开启了她的演讲。她幽默地解释道,之所以要精确到分钟,是因为在人工智能领域,时间本身已经变成了一个极其关键且充满动态变化的度量衡——今天分享的观点代表着当下的切片,可能一个月、一周甚至更短的时间后情况就会发生剧变。她同时声明这仅代表其个人观点,与现在或过去的雇主无关。随后,她抛出了一组震撼的数据对比: 首先是“140 亿(14 billion)”——这是预计到当年年底 GitHub 上的代码提交(Code Commits)总量,相比上一年的约 10 亿次暴增了整整 14 倍。这种惊人飞跃的背后,正是 AI Agent 在研发流程中扮演了日益核心的辅助角色,使得工程团队能够以极度精简、高效的节奏疯狂交付。与此同时,另一个亮眼数字是“150”——这是去年全美各州通过的与 AI 相关的法案总数,而当年提出的法案更是突破千项;到了 2026 年,这一立法速度还在进一步刷新纪录。一边是工程与产品研发的指数级交付速度,另一边是层出不穷的技术监管风暴,两者的碰撞给传统政策与合规专业人员带来了前所未有的严峻考验。 - **GitHub 预计代码提交量**:从上年度的约 10 亿次激增至 140 亿次(14 倍暴增)。 - **美国州级 AI 立法**:去年提案超 1,000 项,正式通过 150 项,今年增速仍在攀升。 --- ### [02:12](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=132s) 传统合规的六大被动维度 面对这种时代碰撞,回顾政策与合规岗位几十年来行之有效的传统模式便显得尤为必要。过去在相对稳定的商业和技术周期中,合规职能通常被划分为六个核心维度,每一个角色都曾发挥过卓越的作用: 1. **调查员(Investigator)**:出现突发违规或安全事故后,负责介入并查明真相; 2. **仲裁者(Arbiter)**:当两个团队在规则适用上产生冲突时,充当拍板定夺的法官; 3. **解释者(Interpreter)**:将晦涩难懂的法律条文和监管指南“翻译”成人话; 4. **执法者(Enforcer)**:负责判定某项行为是否越界,并执行相应的惩戒后果; 5. **顾问(Advisor)**:在极度紧迫的时间和极度有限的信息约束下,提供尽可能的专业建议; 6. **领域专家(Domain Expert)**:研读数百页监管细则,牢牢把握行业动态以应对咨询。 然而,剖析这六大维度会发现一个致命的共同点:“每一个角色全都是响应式(Responsive)的,都在原地等待输入”。调查员等待事故发生,仲裁者等待矛盾爆发,专家等待别人提问。在过去,一项重大法规可能几年才落地一部,合规人员有充裕的时间研读、宣贯、推行并做内部审计;但如今,在 AI 驱动的代码洪流与法规爆发下,这种被动响应模式已经不堪重负。合规人员必须前移关口,从被动的“问题解决者(Problem Solvers)”转变为主动的“问题定义者(Problem Definers)”。 --- ### [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) 面向 AI 速度的未来态:从响应者到构建者 顺应 AI 时代的演进并不意味着彻底抛弃调查、研判或专业把关等基本功,而是要求合规专业人员经历一场底层范式的升级,全面转向“构建者(Builder)”状态: ```mermaid flowchart LR accTitle: 合规角色从响应式向构建者演进 subgraph 传统响应式角色 D["领域专家 Domain Expert"] A["合规顾问 Advisor"] E["执法者 Enforcer"] I["解释者 Interpreter"] AR["仲裁者 Arbiter"] INV["调查员 Investigator"] end subgraph 现代构建者角色 ARC["架构师 Architect"] P["合作伙伴 Partner"] ENG["工程师 Engineer"] INT["集成者 Integrator"] DES["设计师 Designer"] RES["研究员 Researcher"] end D --> ARC A --> P E --> ENG I --> INT AR --> DES INV --> RES ``` - **领域专家 ➔ 架构师(Architect)**:不再仅作为知识库,而是亲自搭建企业内部控制机制的坚实基石; - **顾问 ➔ 合作伙伴(Partner)**:在产品生命周期的更早阶段深入介入业务与研发; - **执法者 ➔ 工程师(Engineer)**:最关键的跃迁在于放弃“事后追责与惩罚”,转向在风险发生前“直接构建代码级或流程级的防护门禁(Gate)”; - **解释者 ➔ 集成者(Integrator)**:告别单向的法律翻译,将政策机制深度集成到终端用户的实际工作流中; - **仲裁者 ➔ 设计师(Designer)**:将业务团队寻找的“政策例外”或“绕过手段”视为流程失效的信号,协同业务进行早期重构; - **调查员 ➔ 研究员(Researcher)**:运用取证和访谈技能,在项目立项前主动挖掘痛点、映射潜在故障点,而非坐等事故爆发。 基于这种转变,Alexandria 提出了一个极具未来感的断言:在接下来的几年里,政策与合规专业人士将会交付(Ship)出最优秀的产品。随着监管条文激增、AI Agent 全面加速工作节奏以及 AI 渗透率在各组织和国家间不断深化,“何谓构建良好的治理体系(Well-built Governance)”将成为行业核心议题。 --- ### [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) 维特鲁威三原则与“政策即产品” 在科技领域,“构建者(Builder)”一词经常被泛化使用。为了给它一个精准的定义,演讲将视线回溯至两千年前古罗马建筑大师维特鲁威(Vitruvius)及其传世著作《建筑十书》(*De Architectura*)。书中提出了两项对现代合规建设极具启发的洞见: 第一,**卓越的建造者必须具备广博的通识视野**。维特鲁威认为建筑师不能只懂盖楼,还必须精通绘画、几何、历史、数学、音乐、医学、法律及天文等,因为“一座建筑必须伫立于真实世界之中,而非仅仅存在于图纸之上”。这恰好呼应了合规专业人员向多维构建者转型的必要条件。 第二,**优秀建筑的三大基石:坚固(Firmitas)、实用(Utilitas)、愉悦(Venustas)**。如果将这三大古典原则映射到企业政策上: - **坚固(Firmitas)**:政策是否牢不可破?能否通过内部审计?能否经受住突发事件和监管机构的严格盘查?合规界向来以此为立身之本,“坚固”已深植于行业基因之中; - **实用(Utilitas)**:政策是否具备实用性与自助化能力?一名软件工程师在周五下午赶着发版时,能否自助查阅、读懂该规则并顺利完成合规交付? - **愉悦/美观(Venustas)**:政策是否带来了良好的交互体验?大家是否发自内心地愿意使用它? 现实情况是,过去 2000 年来,如果一个结构在三项指标中仅满足了一项(坚固),那就是“糟糕建造”的典型定义。传统的企业政策虽然极其“坚固”,但在使用者眼中往往偶尔才“有用”,且“几乎从未让人感到愉悦”。真正的构建者必须对“产品在最终使用者手中的实际运行效果”负全责——**政策就是一种产品,它拥有真实的用户、体验以及客观存在的采用率(Adoption Rate),无论你是否主动去度量它。** --- ### [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) 政策产品化的前两个阶段:发现与原型 将“政策即产品(Policy as Product)”落实到日常实践中,合规人员的工作流程便能完全复用成熟的产品生命周期模型:**发现(Discover)、原型(Prototype)、交付(Ship)、迭代(Iterate)、规模化(Scale)**。 在本次分享中,Alexandria 重点拆解了前两个阶段的落地方法: ```mermaid flowchart TD accTitle: 政策即产品的前期阶段工作流 subgraph Phase1["第一阶段:发现 Discover"] A1["深入实际业务行为现场"] --> A2["发掘真实痛点,拒绝道听途说"] A2 --> A3["诊断核心问题:'在动笔写政策前,你和谁聊过?'"] end subgraph Phase2["第二阶段:原型 Prototype"] B1["抛弃'官方定稿'心态,快速起草初版"] --> B2["明确打上'Prototype'标签,允许暴露缺陷"] B2 --> B3["向反应最强烈的核心利益群体策略性宣贯与验证"] end Phase1 --> Phase2 ``` 1. **发现阶段(Discovery)**:必须深入到实际业务行为发生的现场,探寻用户的真实痛点,而不是依靠道听途说的二次转述。作者回忆起早年在执法部门审查数百家企业政策的经历,那些政策无一例外文笔严谨(极度坚固),但最大的脱节永远发生在实用性上。在这一阶段,最核心的诊断性提问就是:“**在你动笔撰写这项政策之前,你到底跟谁聊过?**” 2. **原型阶段(Prototype)**:在产品开发逻辑中,第一版原型的天然使命就是“暴露出错误并接受失败”,因为认知正是从失败中迭代而来的。然而合规领域的传统惯性却恰恰相反——习惯将其视作一份神圣的官方文件,非要经过字斟句酌、反复层报后,在“揭幕日”以完美坚固的姿态盛大推出。正确的做法应当是快速起草初稿,明确打上“原型(Prototype)”标签,并策略性地抛给那些预计反弹最大、反应最激烈的业务团队进行压力测试与早期碰撞。 ### [12:36](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=756s) 原型测试:以真实用例检验政策规则 在制定政策规则时,可以通过快速原型设计来验证其实效性。一个极具实操性的建议是:针对某一特定规则拟定几个不同版本的草案,将其分发给三个不同的业务团队,并邀请他们结合具体的业务用例,一步步演示如何实际应用该规则。这种做法不仅能在政策正式发布后的实施阶段沉淀出鲜活的案例研究,还能为最终发布版本的措辞和方向提供清晰指引。在这一阶段,政策制定者应当提出的核心诊断问题是:“在有人完成测试之后,这项政策发生了哪些改变?” - **多版本测试**:向不同团队提供规则草案的多个变体,以实际用例压力测试规则的可行性与理解门槛。 - **双重价值**:既为正式推行积累了可复用的落地案例,又明确了发布前的修改和优化方向。 --- ### [13:02](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=782s) 正式发布与 GTM 策略:发布不等于采纳 重新审视政策的“终点线”至关重要。传统观念往往在政策获得审批并正式公布的那一刻就开香槟庆祝,但 Alexandria de Aranzeta 直言:“发布不等于采纳,审批不等于采纳,宣贯活动也不等于采纳。”政策需要引入产品上市(Go-To-Market, GTM)思维。借鉴在初创公司担任产品市场负责人的实战经验,推广政策应当聚焦三大要素: ```mermaid flowchart LR accTitle: 政策 GTM 三大核心要素 subgraph GTM["政策上市策略 (GTM)"] direction LR A["用户细分<br/>(Segmentation)<br/>明确优先触达群体"] --> B["场景触达<br/>(Presentation)<br/>合适时机/渠道/信息"] B --> C["工作流集成<br/>(Integration)<br/>无缝嵌入业务路径"] end ``` 1. **细分受众(Segmentation)**:明确优先触达谁?如何完成首次触达,并在后续每一次互动中持续维系? 2. **场景呈现(Presentation)**:是否在恰当的时间、恰当的场合,以恰当的表达方式触达目标受众,从而实现预期的合规效果? 3. **流程嵌入(Integration)**:政策具体嵌入到了业务团队的哪个工作流或日常行为路径之中? 在这一阶段,团队应当扪心自问的关键诊断问题是:“你的政策实际采纳率(Adoption Rate)到底是多少?” --- ### [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) 持续迭代:把咨询与疑问转化为数据点 迭代本质上是构建正向反馈循环的核心环节。当业务团队针对政策中某一条款的咨询和豁免申请激增到 20 次、50 次、100 次乃至 250 次时,这就形成了一个明确的信号——说明该条款在实际执行中存在卡点,是时候在内部重新审视并修改它了。各组织可以根据实际情况设定触发阈值。构建者(Builder)思维会将这些业务疑问视为宝贵的“数据点”而非干扰。 在这个阶段,政策制定者需要诚实面对一个直戳痛处的问题:“究竟有哪些政策是因为它行之有效而被保留下来,又有哪些仅仅是因为当初跨部门对齐‘实在太艰难’而不舍得动?我们每个人心里都清楚是哪一个。” --- ### [14:26](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=866s) 规模化与工程协同:将合规内生于工具链 最优秀的政策必然体现了古罗马建筑学中的实用性(*Utilitas*)原则——它们真正被大家用起来了。因为只有政策被使用,它才会被遵循;只有被遵循,安全防护措施才能真正落地生效。在这一阶段,合规团队的角色发生了质的跃迁,他们不再是事后审查者,而是与工程团队并肩作战的“共建者”(Co-builder)与“共同设计者”(Co-designer)。 核心宗旨在于:“在工作正在发生的地方进行构建,在工作走向的未来规模化部署工具。”此时需要检验的诊断问题是:“你的政策到底有多少已经以代码和工具的形式内置(Built-in)到了系统之中?” --- ### [15:05](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=905s) 构建者时代:从坚固耐用走向实用与愉悦 Alexandria de Aranzeta 总结了未来状态的五个阶段、合规专家的六大维度以及五道诊断问题。她引用古罗马建筑师维特鲁威(Vitruvius)在两千年前提出的建筑三原则作为总结:坚固(Firmness / *Firmitas*)、实用(Usefulness / *Utilitas*)与美观/愉悦(Delight / *Venustas*)。 合规与政策行业早已在“坚固耐用”上千锤百炼、运用纯熟,并在这方面持续保持卓越。然而,AI 时代的根本转变在于,它正在将每一个专业技能都转变为一门“构建学科”(Building Discipline)。这使得如何让政策兼具“实用性”与“愉悦感”成为需要规模化深耕的核心课题。演讲最后满怀信心地鼓励全场:“在座的每一位政策与合规专业人士,不论是当下还是未来,都是名副其实的构建者(Builder)。” ## Notable quotes > [02:12](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=132s) 每一个角色全都是响应式(Responsive)的,都在原地等待输入 — Alexandria de Aranzeta > [04:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=292s) 在接下来的几年里,政策与合规专业人士将会交付(Ship)出最优秀的产品 — Alexandria de Aranzeta > [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) 一座建筑必须伫立于真实世界之中,而非仅仅存在于图纸之上 — Alexandria de Aranzeta > [07:14](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=434s) 政策就是一种产品,它拥有真实的用户、体验以及客观存在的采用率(Adoption Rate),无论你是否主动去度量它 — Alexandria de Aranzeta > [10:49](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=649s) 在你动笔撰写这项政策之前,你到底跟谁聊过? — Alexandria de Aranzeta > [12:36](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=756s) 在有人完成测试之后,这项政策发生了哪些改变? — Alexandria de Aranzeta > [13:02](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=782s) 发布不等于采纳,审批不等于采纳,宣贯活动也不等于采纳 — Alexandria de Aranzeta > [13:02](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=782s) 你的政策实际采纳率(Adoption Rate)到底是多少? — Alexandria de Aranzeta > [13:52](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=832s) 究竟有哪些政策是因为它行之有效而被保留下来,又有哪些仅仅是因为当初跨部门对齐‘实在太艰难’而不舍得动?我们每个人心里都清楚是哪一个 — Alexandria de Aranzeta > [14:26](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=866s) 在工作正在发生的地方进行构建,在工作走向的未来规模化部署工具 — Alexandria de Aranzeta > [14:26](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=866s) 你的政策到底有多少已经以代码和工具的形式内置(Built-in)到了系统之中? — Alexandria de Aranzeta > [15:05](https://www.youtube.com/watch?v=h9p7AeX8JkY&t=905s) 在座的每一位政策与合规专业人士,不论是当下还是未来,都是名副其实的构建者(Builder) — Alexandria de Aranzeta ## Mentioned Alexandria de Aranzeta, Boeing, GitHub, Vitruvius, 《建筑十书》(De Architectura), Ai4 ## Video description Alexandria de Aranzeta - Data and AI Governance Policy Lead, Boeing What if your policy had an adoption rate? Keeping pace with AI demands a shift from a reactive way of working to an entirely different operating system. This talk will trace a phased roadmap for policy to meet the AI moment, the diagnostic questions to pressure-test how policy gets built today, and the one skill that will define the profession's next decade. [Source](https://www.youtube.com/watch?v=h9p7AeX8JkY)

Source quotes

[2:12] Alexandria de Aranzeta: 每一个角色全都是响应式(Responsive)的,都在原地等待输入 [4:52] Alexandria de Aranzeta: 在接下来的几年里,政策与合规专业人士将会交付(Ship)出最优秀的产品 [7:14] Alexandria de Aranzeta: 一座建筑必须伫立于真实世界之中,而非仅仅存在于图纸之上 [7:14] Alexandria de Aranzeta: 政策就是一种产品,它拥有真实的用户、体验以及客观存在的采用率(Adoption Rate),无论你是否主动去度量它 [10:49] Alexandria de Aranzeta: 在你动笔撰写这项政策之前,你到底跟谁聊过? [12:36] Alexandria de Aranzeta: 在有人完成测试之后,这项政策发生了哪些改变? [13:02] Alexandria de Aranzeta: 发布不等于采纳,审批不等于采纳,宣贯活动也不等于采纳 [13:02] Alexandria de Aranzeta: 你的政策实际采纳率(Adoption Rate)到底是多少? [13:52] Alexandria de Aranzeta: 究竟有哪些政策是因为它行之有效而被保留下来,又有哪些仅仅是因为当初跨部门对齐‘实在太艰难’而不舍得动?我们每个人心里都清楚是哪一个 [14:26] Alexandria de Aranzeta: 在工作正在发生的地方进行构建,在工作走向的未来规模化部署工具 [14:26] Alexandria de Aranzeta: 你的政策到底有多少已经以代码和工具的形式内置(Built-in)到了系统之中? [15:05] Alexandria de Aranzeta: 在座的每一位政策与合规专业人士,不论是当下还是未来,都是名副其实的构建者(Builder)

Source quotes

Alexandria de Aranzeta: What if your policy had an adoption rate? [0:04] Alexandria de Aranzeta: 14 billion and 150. [4:52] Alexandria de Aranzeta: policy and compliance professionals are going to be shipping the best products. [7:14] Alexandria de Aranzeta: stand within a world, not just on a page. [7:14] Alexandria de Aranzeta: Firmitas for days. [10:49] Alexandria de Aranzeta: Who did you talk to before you wrote it? [12:36] Alexandria de Aranzeta: What changed after someone tested? [12:36] Alexandria de Aranzeta: What is your policy's adoption rate? [13:52] Alexandria de Aranzeta: Which policy are you keeping because it works and which one because it was really hard to align? We all know the one. [13:52] Alexandria de Aranzeta: How much of your policy is actually built in?

Original transcript

[0:04] Hi everyone. I'm Alex Di Arenzo Zetta. And it's  August 5th, 2026. It's about 11:22 a.m. And the [0:14] reason I'm giving you the time is because an AI  that is a very meaningful unit of measurement. [0:19] Uh and everything I'm about to share with you  today is indicative of this moment in time. [0:25] Uh my views are about this subject or of today.  Meaning probably in a month from now they may [0:31] not be relevant. Perhaps a week. Uh certainly  not a year. And also while we're on the subject [0:37] of viewpoints, please note that these are my  own. Uh they don't represent the viewpoints of [0:41] anyone I used to work for either presently or  past. But I want to get back to measurement [0:47] um because this is we have some very exciting  numbers. 14 billion. That's one. Wow. [0:55] That's the number of GitHub code commits that are  projected by the end of this year. That's a 14x [0:59] increase. Last year was about a billion. That's  still momentous. Right? So what does that mean? [1:06] That means our engineering counterparts are  shipping very quickly. They're also shipping [1:12] very leanly. Um you know, this is because the  rise of AI agents in assisting that process. [1:20] Now, this velocity is one thing. But we also  see another really fantastic number, 150. [1:28] And 150 is how many AI-related bills that were  passed last year by US states. It's actually a [1:34] really impressive number. Over a thousand were  proposed. Proposed. Now already as of this year [1:40] in 2026, the numbers are surpassing last year's  numbers. Right? So we have an incredible velocity [1:47] seen in engineering and product development. We  have an incredible volume that we're seeing at [1:51] a state level in terms of laws being passed for  technology. Uh it's quite unprecedented. So, you [1:58] what does that mean? Well, what does that mean for  policy professionals, compliance professionals? [2:03] Uh, well, that means that in organizations this  is where we also need to meet the AI moment. [2:12] But, let's look at the current state. The current  state is really, uh, how this role has been done [2:18] for decades. It has been done very well for  decades in this environment and with this model. [2:25] So, if you map the dimensions of a policy  compliance professional, and one could argue that [2:28] there are many more than six, I understand that.  Um, but, you know, here is what we might see. [2:35] You're an investigator, right? Something happened,  and now you have to figure out what it is. [2:41] Uh, you're also an arbiter. Uh, two teams  disagree about what rule they need to follow [2:46] and you're the tiebreaker. You're the judge. Uh,  you're also an interpreter. You interpret legal [2:52] language, regulatory language, and guidance  into human language. You're an enforcer, [2:59] right? Something crossed the line at some point,  and you're the one that says what line that was, [3:05] whether it happened, and you also have to meet  out the consequences. You're the enforcer, [3:10] uh, or you're the you're the advisor. So, you give  the best guidance you can, and it's usually under [3:15] serious time constraints and usually with the  most limited amount of information on hand. [3:22] You're the domain expert. You're the person.  You've read several hundred pages of text. [3:27] You've read the guidance. You have a  pulse on what the industry is doing. [3:32] Do you notice anything about these dimensions? [3:38] Every single one of these is responsive.  Every single one waits for an input. [3:44] Right? The investigator needs an incident. Um, the  arbiter needs a dispute, right? The domain expert, [3:50] uh, needs needs a question, right? They need a  regulation. Um the arbiter needs that conflict. [3:58] This has made a lot of sense uh in past  decades because of the critical requirements of [4:03] organizations, which those critical requirements,  you know, that criticality is not changing. Uh [4:09] but, you know, also that the pace of change could  really sustain this model and way of doing things. [4:15] Um and, you know, a major regulation may  be landed every year, every few years. [4:19] Uh you time to read it, your time to interpret it,  your time to socialize it, uh digest the guidance, [4:25] right? Uh audit against it. But with AI's speed  and the velocity that we just talked about and the [4:31] volume that we're just seeing in laws uh being  passed, infrastructure scaling, uh the number [4:37] of proposed laws is is slated to increase.  Uh organizational problem solvers, like us, [4:44] um need to move move a little bit uh ahead  in the process and become problem definers. [4:52] So, now the future state built for AI  speed. One thing that I'm not going to say, [4:58] I'm not going to say that compliance and policy  professionals need to stop being an investigator, [5:02] they need to stop being a domain expert, they  need to stop being an advisor, an interpreter, [5:06] an arbiter. Um all of these things still  ring true. But AI is demanding a shift and [5:13] the domain expert now becomes an architect.  This is really the foundation upon which [5:18] controls are being built. This is an incredibly  important role. The advisor becomes a partner. [5:26] This means you're more involved much earlier on in  the process. The enforcer becomes an engineer, and [5:31] this is probably the most interesting shift that  I'm predicting, um is that, you know, typically [5:37] enforcement is after the fact. And the tool  or instrument that you have are consequences. [5:45] But now you're actually able to  build the gate before you get there. [5:48] Uh the interpreter becomes an integrator.  Well, it's it's no more unidirectional. [5:54] Uh no more translating uh legal  or regulatory guidance, you know, [5:58] just into human language. It's actually  reaching users at an individual user level. [6:05] The arbiter becomes a designer. This  is also an incredibly interesting one. [6:09] An example of this is focusing on exceptions or  workarounds that you're seeing to policy. When [6:13] those are signals of things not working, this is  where you can co-design earlier on in the process. [6:19] Right? Adapting that role of advisor. The  investigator becomes a researcher. So, [6:24] you can still use all the same investigative  skills that you have in your toolkit, [6:28] right? Evidence gathering, interviewing, um and  focus on discovering the problems and mapping [6:35] the fail points up front versus uh waiting for  them to happen. And so, this is the futurist [6:41] claim that I'm going to stake here today is  that we will see in the next couple of years [6:46] policy and compliance professionals are going  to be shipping the best products. And that [6:51] is because regulations added to the books are  scaling. Agents are also scaling work velocity. [6:59] Also, the penetration rate of AI continues to  increase across organizations, right? And nations. [7:05] We are likely to hear a lot more about what is  well-built governance in the next year or two. [7:14] But we need to level set because builders are  term that gets thrown around quite often in tech. [7:19] Uh and I mean something  very specific by this word. [7:23] Uh but to do so, we need to travel back in  time, yep, time again, uh about 2,000 years. [7:30] So, Vitruvius, if anyone's heard of him,  he was a Roman architect and engineer [7:34] from about the 1st century BCE. He wrote  uh a treatise called De Architectura. [7:41] It's about 10 books. Uh and everything I'm  going to share today came from the first one. [7:46] And what's interesting about this is it's one  of the only surviving treatises on building [7:50] that exists from classical antiquity. Right? And  it's influenced everything. Look around this room. [7:58] Two things really matter from De Architectura  for this room. The first thing, Vitruvius argues [8:06] that an architect cannot just know  buildings. It's an interesting thought. [8:12] He says that the builder must be broadly educated.  They must know drawing, geometry, history, [8:19] uh math, music, medicine, law, astronomy,  the arts. Because he says a structure [8:27] must be able to stand within a world, not  just on a page. Does that sound familiar? [8:36] Think about the dimensions we just  covered in the shift to the builder state. [8:42] I would argue that these dimensions may be  considered a prerequisite for being a builder. [8:49] The second thing that Vitruvius says is that to  build well, well, that requires three conditions. [8:55] Firmitas, Utilitas, Venustas.  Firmness, usefulness, delight. [9:06] Firmitas, does the policy do what it's intended to  do? Is it strong? Does it pass an internal audit? [9:13] Does it stand up after an incident? Uh does it  pass regulatory scrutiny? And now generally, [9:18] I think the answer is probably yes, because  Firmitas is is something that's baked into [9:21] the profession. Firmitas is actually  part of our brand. Firmitas for days. [9:27] Utilitas, is the policy useful? More importantly,  is it self-serve? Can the engineer on a Friday [9:36] afternoon look at a policy for a rule, understand  it, and help them ship? Perhaps. Now, venustas, [9:47] does the policy offer a good experience? Do  people want to use it? I'll wait on that one. [9:58] Because the truth is the emphat- emphasis has  always been on the first, firmness. That is [10:04] something that we do very well. Policies are very  good at being firm. They are occasionally useful [10:09] uh in the eyes of a user and almost never  delightful. One out of three, and for 2,000 years, [10:17] one out of three has been the definition of bad  building. So, a builder then, by my definition, is [10:25] someone who takes accountability for the product  working in the hands of the people who use it. [10:31] Policy is a product. Policy has users. Policy  has experience. Policy has adoption rates, [10:38] whether you measure them or not. And if policy  is a product, then the policy compliance [10:42] professional's job, well, their job description  and their workflow actually already exists. [10:49] And here it is. We have five phases.  Discover, prototype, ship, iterate, scale. [10:57] Every product leader in this building, many of  you may also be product leaders in this room, [11:02] there it is, another dimension. Every one of you  live on this journey. And I want to walk through [11:07] each phase and show you how policy as product  is baked in to each one of these in practice. [11:16] First, discovery. Discovery means actually  going where the behaviors are happening, [11:21] understanding a user's actual problem, not the  problem assumed from the things you heard that [11:25] someone else told you. Uh now, in practice, when  I worked in enforcement uh years ago, uh it was [11:31] my job to review hundreds of companies' policies,  big and small. Generally speaking, policies were [11:39] almost never poorly written. Firmitas. But the gap  often arose uh in utilitas, how useful they were. [11:50] Now, a question you might ask, a  diagnostic question at this phase is, [11:55] "Who did you talk to before you wrote it?" [12:00] Prototype. [snorts] When treating policy as a  product, the first version always exists to be [12:05] wrong. I mean, in product, the first one always  fails. It's actually built to fail. That's how you [12:08] learn. Now, in compliance, we tend to treat it as  uh as an official filing, right? It is polished, [12:15] it is socialized, it is unveiled. And on  unveiling day, it is firm, it is ready to go. [12:23] But I suggest drafting quickly, labeling it a  prototype, very clear about that, socializing it [12:31] strategically, of course, with the groups that  you think will have the most reaction to it. [12:36] One suggestion is um perhaps drafting a few  different versions of a particular rule, [12:43] putting it in front of three different teams, and  asking them to walk you through a use case with [12:47] that rule. Not only do you get get a case study  when it's time for implementation post launch, [12:52] um but you always uh also have  direction in terms of publication. [12:58] And ask yourself, what  changed after someone tested? [13:02] Ship. Evaluate the finish line. Uh often policy is  lauded once it's approved and once it's published, [13:11] but uh publication isn't adoption. Uh approval  isn't adoption, campaigns aren't adoption. [13:17] Think it go-to-market. And so, when I  led product marketing uh in startups, [13:21] I would obsess about three things. First,  segmentation, who are we prioritizing? [13:26] How do I reach them for the first time and then  every single time thereafter to presentation? [13:31] Are we targeting the right group at the right  time in the right venue with the right messaging [13:38] expecting the right outcome that we've defined?  And third, integration. Where are we plugging in [13:43] to that workflow or that behavior path? You may  ask here, what is your policy's adoption rate? [13:52] Now, iterate. This is very important because  iteration is is actually part of the feedback [13:56] loop. Um so you can consider, for example, um  if you start to see 20, 50, 100, 250 requests [14:04] about a particular clause in a policy, it may  be time to revisit that, right, internally. Um [14:10] you can set your own thresholds here, what makes  sense. But use this as an opportunity to learn [14:13] because a builder thinks of this as a data  point. You may ask yourself, which policy are [14:18] you keeping because it works and which one because  it was really hard to align? We all know the one. [14:26] Lastly, scale. The best policies are ones  that, well, utilitas, they're being used. [14:32] Right? Because if they're being used, they're  being followed. If they're being followed, right, [14:35] safeguards are happening. Now, this is really  where compliance becomes a very strong partner, [14:44] a co-builder, a co-designer alongside engineering.  Because the big takeaway here is you want to build [14:51] where the work is happening and you want  to scale tools where the work is going. [14:58] May ask yourself at this phase, how much  of your policy is actually built in? [15:05] So here we have the five phases, the road map of  the future state, six dimensions of the policy and [15:12] compliance professional, in addition to the five  diagnostic questions that we just walked through. [15:21] Now, 2,000 years ago, you know, Vitruvius  wrote that building well has three conditions: [15:26] firmness, usefulness, and delight. Um, this  is a profession that we all know is mastered [15:32] firmitas a very long time ago. Right?  We continue to do that very well. But, [15:37] what's changed is that AI is turning every  single skill set into a building discipline. [15:42] And that makes usefulness and that makes  delight, beauty the really important work [15:49] that we need to scale. Uh, but you know what?  Um, this work I believe will not only happen, [15:55] but I believe it will happen very, very well  because uh, I know that each and every policy [15:59] and compliance professional in this room is  now and in the future a builder. Thank you.