Most data infrastructure conversations start at the bottom of the stack. This one starts with the engineers who break it. ML teams move fast by default and when the platform doesn't give them safe abstractions, they build unsafe ones. The result isn't a people problem; it's a missing infrastructure layer. This session makes the architectural case for internal developer platforms designed specifically for ML workloads: what to expose, what to hide, and where the guardrails need to live in code rather than a wiki. We'll dig into the concrete decisions that separate platforms that scale from ones that become support tickets: compute isolation boundaries, data contract enforcement at the platform layer, and the abstraction patterns that let ML engineers self-serve without reaching past the guardrails into shared infrastructure. Key takeaways: →A framework for where platform ownership ends and ML engineer ownership begins and why most teams draw that line in the wrong place → The infrastructure primitives that matter most for ML workloads, and how to expose them without exposing everything underneath → What "paved roads" actually need to enforce to stop becoming optional