The situation
AI adoption at SoundCloud was happening the way it happens everywhere: enthusiastically, in parallel, and without a shared spine. Teams across product, engineering, legal, marketing, trust & safety, and operations were each evaluating vendors, writing their own prompts, and forming private opinions about what was safe. The energy was real. The duplication and risk were also real.
The actual problem
The request was
“Pick our AI tools and set the policy.”
Discovery showed
The company did not have a tooling problem. It had a decision-making problem, no shared way to judge which work should be automated, who owned the outcome, and what evidence made a use case safe to ship.
A policy alone would have produced governance theater: a document nobody reads, applied by a committee nobody wants to schedule. What was actually missing was an operating model, access, routing, and guardrails built into the path of least resistance, plus a roadmap that ranked opportunities by impact rather than by whoever asked loudest.
What I learned
- Interviewed leaders across six functions to inventory in-flight AI experiments and the decisions each one was actually blocked on.
- Mapped support, trust & safety, monetization, and internal ops workflows against volume, cost, error tolerance, and reversibility.
- Analyzed spend and shadow usage to size the real cost curve rather than the projected one.
- Pressure-tested legal and privacy constraints early, so the roadmap was built inside the real boundaries instead of discovering them at launch.
How I framed it
Exhibit
Task Autonomy Framework
- 01
Tier 1: Repetitive, low ambiguity
- Knowledge depth
- Shallow, documented
- AI suitability
- High
- Integration
- Read-only
- Autonomy level
- Full autonomy, sampled review
- 02
Tier 2: Judgment inside known rules
- Knowledge depth
- Policy + context
- AI suitability
- High with retrieval
- Integration
- Read + write
- Autonomy level
- Autonomous, human on exception
- 03
Tier 3: Judgment with real consequence
- Knowledge depth
- Tribal + policy
- AI suitability
- Assistive
- Integration
- Write with audit
- Autonomy level
- Human in the loop, always
- 04
Tier 4: Novel, contested, or regulated
- Knowledge depth
- Expert only
- AI suitability
- Drafting only
- Integration
- None
- Autonomy level
- Human decides, AI supports
| Knowledge depth | AI suitability | Integration | Autonomy level | |
|---|---|---|---|---|
| 01Tier 1: Repetitive, low ambiguity | Shallow, documented | High | Read-only | Full autonomy, sampled review |
| 02Tier 2: Judgment inside known rules | Policy + context | High with retrieval | Read + write | Autonomous, human on exception |
| 03Tier 3: Judgment with real consequence | Tribal + policy | Assistive | Write with audit | Human in the loop, always |
| 04Tier 4: Novel, contested, or regulated | Expert only | Drafting only | None | Human decides, AI supports |
The tiers did the political work: teams stopped debating whether AI was 'safe' in the abstract and started placing individual tasks on a shared ladder.
Exhibit
Enterprise AI Reference Architecture
01Governance & policy
Data classification, acceptable use, vendor risk, retention
02Evaluation & telemetry
Eval harnesses, quality signals, logging, cost and latency
03Orchestration & agents
Shared prompt and tool registry, agent patterns, handoff rules
04Model access & routing
One gateway, per-team budgets, model selection by task tier
05Data & retrieval
Classified sources, retrieval boundaries, audit on sensitive flows
Shared infrastructure, not point solutions, the difference between 30 pilots and one platform.
What we built
- 01An AI-first operating model aligning product, engineering, legal, marketing, trust & safety, and operations around one strategy.
- 02A data-driven AI roadmap that surfaced the opportunities with the biggest payoff across the business and sequenced quick wins against platform investment.
- 03Centralized enterprise AI access, routing, and governance with cost and risk controls built in.
- 04The AI Collective, an internal community of practice that accelerated responsible experimentation without approval friction.
- 05An internal AI system with BigQuery as the data spine: Zendesk API data flowed into BigQuery, product analytics were already there, Finance and Revenue data came through Looker, and Product Marketing content from Google Drive plus Engineering docs from GitHub were moved into GCP buckets. An agent sat over that connected context for deep analysis.
- 06An evaluation model for support AI that judged whether the customer's problem was resolved, not whether the bot held the conversation.
She consistently cut through the noise, evaluating opportunities and pressure-testing their potential.
Maria Von WatzdorfVP, Product at SoundCloudRead in full →My role
- Strategy
- Owned the company-wide AI strategy and roadmap end to end.
- Architecture
- Set the reference architecture with engineering and data partners, including the BigQuery-centered context layer the internal agent read from.
- Governance
- Built classification, access, and vendor-risk standards with legal and security.
- Facilitation
- Founded and ran the AI Collective; office hours, demos, enablement.
- Evaluation
- Measured resolution, not containment: what happened to the ticket afterward, whether it escalated, what CSAT said, which content gaps caused it, and where people were stuck in bot loops.
The outcome
- Support AI was judged on whether the customer's problem was resolved. Containment on its own never counted as success.
- Connecting ticket, bot, and product data in one place contributed to roughly 20% better decision accuracy on where to invest.
- Repeat contacts, escalations, CSAT, content gaps, and bot loops became the operating view executives looked at.
- Moved AI spend from untracked shadow usage into governed, budgeted, attributable routing.
- Left behind reusable AI Ops patterns that continued to scale past the original implementations.
What I'd do differently
I underestimated how much of this job was social. The architecture was tractable within weeks; the trust took quarters. If I did it again I would launch the community of practice first and let the platform follow the demand it surfaced, rather than the other way around.