Platform team owns AI tooling
When AI tool adoption is owned by individual champions or informal volunteers, it scales up to a point and then stops.
- ·Platform team formally owns AI tooling (selection, provisioning, security, baseline configuration)
- ·Internal Developer Platform includes an AI layer (standardized agent setup, self-service provisioning)
- ·Standardized agent setup exists per team (every team has a working AI environment by default)
- ·New developer onboarding includes AI tool setup that completes in under 30 minutes
- ·Platform team tracks adoption breadth (% of developers with active AI setup)
Evidence
- ·Platform team charter or responsibility matrix including AI tooling ownership
- ·IDP configuration showing AI tool provisioning layer
- ·Standardized agent setup scripts or templates per team
What It Is
When AI tool adoption is owned by individual champions or informal volunteers, it scales up to a point and then stops. The champion model works well for 2-3 pilot teams. It breaks down when you're trying to drive consistent adoption across 10-15 teams with different codebases, workflows, and technical contexts. The transition from champion-owned to platform-owned AI tooling is the organizational shift that separates L2 (Guided) from L3 (Systematic).
Platform team ownership means that AI tooling is treated as infrastructure, not as individual practice. The platform team is responsible for selecting and provisioning AI tools, maintaining integrations with the existing developer platform, setting baseline configuration standards, handling security and compliance requirements, and measuring adoption across the organization. Individual teams can customize within the platform's guardrails, but they don't have to solve the foundational problems themselves.
The analogy to CI/CD is useful here. Early in an organization's DevOps journey, a few motivated developers set up CI pipelines for their own teams. Later, a platform team standardizes the CI infrastructure so every team gets a working pipeline without having to build one from scratch. AI tooling is following the same arc. The champion era is the "motivated individuals setting things up for themselves" phase. Platform ownership is the "every team gets it working by default" phase.
Platform ownership also addresses the governance problems that emerge at scale. Security reviews, data handling policies, model selection decisions, cost management - none of these can be handled team-by-team without creating massive inconsistency and risk. The platform team is the right locus for these decisions because they have the scope to make them consistently and the mandate to enforce them.
Why It Matters
- Scales what champions proved - the champion model proves that AI tools work in your environment; platform ownership is how you get those tools to every team without requiring each team to rediscover what the champions learned
- Solves governance at scale - security reviews, API key management, data handling policies, and model selection all need consistent answers across the organization; individual teams cannot provide consistency on their own
- Reduces the tax on product teams - when every product team has to handle its own AI tool setup, integration, and configuration, that is engineering time not spent on product work; platform ownership amortizes the setup cost across the org
- Enables organizational measurement - consistent tooling infrastructure enables consistent measurement; when each team uses a different configuration, aggregating adoption and outcome data is nearly impossible
- Creates the foundation for L4-L5 capabilities - multi-agent orchestration, agent fleet management, and organizational-scale AI workflows are not possible without a platform layer that manages the infrastructure; platform ownership is the prerequisite
Getting Started
-
Audit what exists before building - Before the platform team takes ownership, catalog the current state: which tools are in use, how are they configured, what integrations exist, what security reviews have been completed. The audit reveals what can be standardized versus what needs to be rebuilt.
-
Define the platform team's scope explicitly - Write down what the platform team owns (tool selection, provisioning, security, baseline configuration, adoption measurement) versus what product teams own (workflow-specific customization, team-specific context files, local champions). The boundary matters because ambiguity creates conflict and gaps.
-
Start with the things that should never be per-team - API key management, security review documentation, data handling policies, and cost controls are natural platform-team responsibilities because inconsistency in these areas creates organizational risk. Take ownership of these first; they are also the areas where product teams are most likely to welcome platform team support.
-
Build a self-service provisioning mechanism - Every new developer joining the organization should be able to provision their AI development environment without filing a ticket or waiting for manual approval. Self-service provisioning is the operational definition of "platform ownership" - if developers still need to ask for access, the platform isn't done.
-
Establish a feedback channel from product teams to platform - Platform ownership works when product teams can report what's broken, what's missing, and what would help. Build a lightweight mechanism - a Slack channel, a monthly sync, a shared issue tracker - for this feedback to flow. Without it, the platform team optimizes for what they think teams need rather than what teams actually need.
-
Define the platform team's success metrics - The platform team should be measured on adoption breadth (percentage of developers with a working AI setup), setup time (time from new developer to working AI environment), and incident rate (authentication failures, tool unavailability). These metrics are different from the product team metrics and should be tracked separately.
The platform team's first deliverable should be a "getting started in 30 minutes" guide that gets any developer on any team to a working AI tool setup without needing to ask anyone for help. This guide is the test of whether the platform team has actually solved the onboarding problem.
Common Pitfalls
Platform team as gatekeeper rather than enabler. A platform team that slows down AI tool access through approval queues and manual reviews is worse than no platform team - it creates the illusion of governance while blocking adoption. The platform's job is to make the right thing easy, not to make everything require approval.
Building the platform for the tools you have instead of the tools you'll need. AI tooling is evolving faster than most platform infrastructure. A platform built tightly around a specific vendor's current API will be expensive to change when better tools emerge. Build for the patterns (authentication, provisioning, monitoring) not the specific tools.
Neglecting the champion network. When the platform team takes ownership, there's a risk that existing champions feel displaced or that the champion function atrophies. The platform team and champion network are complementary: the platform handles infrastructure, champions handle workflow knowledge transfer. Both are needed at L3.
Centralizing configuration that should be decentralized. The platform should standardize baseline configuration and security settings. It should not standardize team-specific context files, project-specific prompting approaches, or workflow preferences. Overcentralization creates a lowest-common-denominator experience that doesn't serve any team well.
Not measuring platform team impact. Platform teams have a natural tendency to measure their own activity (tickets closed, tools provisioned) rather than their impact (developer time saved on setup, adoption rate across the org). Activity metrics hide the difference between a platform team that is busy and one that is useful.
How Different Roles See It
Bob's AI program has grown from the original 2-team pilot to 8 teams over the past six months. Each team has a different tool configuration, different security review status, and different levels of champion support. The operational overhead of managing the inconsistency is growing, and Bob has had three security-related questions in the past month that he didn't have consistent answers to.
What Bob should do: Bob should formalize the platform team's ownership of AI tooling as an explicit decision, not as an organic evolution. This means: identifying who on the platform team is responsible for AI tooling (with allocated time, not just "also do this"), defining the scope of their ownership, and commissioning the three initial deliverables that prove the platform is working - a security clearance that applies org-wide, a self-service provisioning mechanism, and a 30-minute onboarding guide. Bob should also communicate the transition to team leads clearly: the platform team is taking over the infrastructure decisions; teams keep their workflow autonomy.
Sarah has been tracking adoption metrics for 8 teams and the inconsistency is making her job increasingly difficult. Team A uses one tool, Team C uses another, Teams D and E have different API configurations, and two teams haven't completed security review. She can't produce a coherent org-level adoption picture from this data.
What Sarah should do: Sarah should use her measurement challenges as the business case for platform team ownership. She should document the specific costs of the current inconsistency: the time she spends normalizing incompatible data formats, the gaps where no data exists, the security questions that don't have consistent answers. This is not a complaint - it is a resource allocation argument. Sarah should propose that the platform team take ownership of the tooling infrastructure, with a specific focus on the four things that would most improve her ability to measure adoption: standardized tooling configuration, consistent authentication approach, a usage telemetry pipeline, and a single security clearance that covers all teams.
Victor has been the de facto platform for AI tooling in addition to his champion role. Developers across multiple teams come to him for setup help, configuration questions, and security escalations. He's spending 40% of his time on infrastructure problems rather than the workflow knowledge transfer that is actually his highest-value contribution.
What Victor should do: Victor should document everything he's been doing informally and propose that it be formally owned by the platform team. He should write a handoff document: here is what developers ask for, here is how I answer it, here is what the platform team needs to build to make my answers unnecessary. Victor should also be explicit with Bob that his current role is not sustainable - he is doing both champion and platform engineer work with time allocated for neither. The solution is not for Victor to work harder; it is for the organization to clarify ownership so that infrastructure questions go to the platform team and workflow questions come to Victor.
Further Reading
From the Field
Recent releases, projects, and discussions relevant to this maturity level.
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.