Great question and a challenge I've worked through across several large enterprise engagements. Here's what has actually worked at scale.

**The core principle: KBs by audience, not by service**

At 10,000+ applications, a service-per-KB model is unmanageable. The proven pattern is a small number of KBs structured by consumer audience and access pattern:

- Employee Self-Service KB — public-facing, plain language, deflection-focused
- Agent/Service Desk KB — L1 resolution content, structured for speed
- Specialized/Domain KB(s) — L2/L3, operations, technical runbooks (one per major domain, not per service)

Three to five KBs total covers most large enterprises. User Criteria handles access, not KB proliferation.

**Service ownership without thousands of KBs**

This is the real design challenge. The answer is taxonomy and metadata, not KB structure:

- Build a shared Category/Subcategory taxonomy aligned to your service tower or CMDB CI Class hierarchy — not individual applications
- Use the kb_knowledge.cmdb_ci field (as Mark noted) to associate articles to specific CIs — this is your service-level linkage
- Add a mandatory Ownership Group field (map to your service owner groups) so ownership is at the article level, not the KB level
- Service owners then filter their view using PA dashboards or a saved list filter on kb_knowledge where cmdb_ci.owned_by = me (or ownership_group = my group)

This gives each service owner visibility into their articles across the platform without requiring their own KB.

**Taxonomy design at scale**

With 10,000+ services, your category structure needs to be tier-based, not flat:
- Tier 1: Major service domains (Infrastructure, End User Computing, Business Applications, Security, etc.) — 8 to 12 max
- Tier 2: Service families within each domain
- Tier 3 (optional): Specific services or CI classes

Avoid letting Tier 3 grow unbounded. If a category has fewer than 5 articles, it probably shouldn't exist yet.

**AI Search and Now Assist readiness**

At this scale, content quality across a unified taxonomy matters more than KB structure for search and AI performance. Standardized titles, mandatory short descriptions, and consistent metadata (especially Business Service and CI linkage) are what make AI Search return useful results across 10,000+ service contexts. KB structure alone won't solve findability.

**What I'd avoid**

- KB per business unit or department — ownership fights and taxonomy fragmentation
- KB per application — unmanageable at your scale
- Relying on KB structure alone to enforce ownership — metadata and governance processes do that job better