Software Delivery · Field note 003
Why AI has become a platform engineering problem
The biggest misconception in enterprise AI is that success depends mainly on choosing the best model. Model selection matters. But once anything reaches production, operational concerns dominate — and none of them are model problems.
Five stakeholders, one platform
Every group touching a production AI system needs something the model itself can't provide:
Developers
need approved access patterns they don't have to negotiate for every project.
Security teams
need visibility into what's calling which model with what data.
Business users
need guardrails that stop them from finding out the hard way.
Architects
need observability that spans every team's usage, not just their own.
Compliance teams
need auditability that holds up outside a demo.
Platform engineering as the multiplier
Platform engineering's job is to create golden paths that make the right way the easy way. For AI, that means approved templates, validated deployment patterns, automated checks, shared secrets handling, standard observability, and common integration approaches — the set of decisions a team shouldn't have to make from scratch every time.
Developer experience is what determines whether any of that actually gets used. If reaching an approved service takes longer than going around it, teams route around it, and governance becomes theater. If the approved path is clear, fast, and well-supported, governance becomes an enabler instead of a checkpoint everyone tries to avoid.
The AI golden path
- Builder or developer
- AI golden path
- Approved template + pipeline
- AI runtime
- Monitoring, evaluation, cost
Operational readiness is architecture
AI systems raise operational questions that don't have obvious owners yet. How do you evaluate result quality over time? How do you detect prompt drift before a user does? How do you know which data was actually used to produce an answer? How do you understand cost by app, user, or department? How do you revoke a tool's access the moment it needs to be revoked? These aren't afterthoughts — they belong in the platform design from day one.
The cloud rerun
This is the same lesson cloud adoption already taught, in the same order. Cloud was first treated as infrastructure procurement — buy compute, stand up servers, move on. It only became durable once organizations recognized it as a platform engineering discipline: standardized onboarding, reusable integrations, lifecycle management, cost controls, monitoring, governance. AI is following the identical trajectory, just faster.
As adoption scales past the first few pilots, every one of those platform capabilities becomes mandatory rather than optional. Skipping them doesn't remove the work — it just defers it to whoever has to debug the incident later.
The dividing line
Platforms scale. Projects repeat.
Organizations that build strong AI platforms enable thousands of users from a common foundation. Organizations that focus only on individual projects keep solving the same onboarding, access, and observability problems from scratch — once per team, forever.
What to do next
- List the platform capabilities that would create the most leverage if built once and reused everywhere.
- Decide whether your AI platform team reports like an infrastructure team or a product team — the incentives differ.
- Pick metrics that indicate platform maturity, not just model performance: onboarding time, reuse rate, incident rate.