AI/ML Platforms7 min read
Shipping data-science models to UIs at a bank
A data scientist shows you a notebook. The model works; the metrics are genuinely impressive; everyone in the demo is nodding. Between that moment and an operations analyst trusting the model's output on a screen at 7 a.m. lies a distance that, in my experience, is almost entirely not machine learning.
I have spent the last several years building that bridge inside a large bank — taking models from research artifacts to production platforms for markets operations. These are the lessons that survived contact with reality. (Everything here is deliberately abstract; the specifics stay behind the firewall, as they should.)
1. The model is the easy 20%
A notebook has no opinions about failure. Production has nothing but. The unglamorous majority of the work is the event-driven plumbing around the model: data arriving as streams rather than CSVs, triggers that fire when new data lands, pipelines that transform and validate before a model ever sees an input, and orchestration that retries, alerts, and explains itself when a dependency misbehaves at 3 a.m.
If your platform story is "we'll schedule the notebook," you do not have a platform story.
2. The UI is where trust is won or lost
Here is the part machine-learning teams underestimate: the model's credibility is decided at the interface. An analyst who watches a grid freeze while loading their dataset does not think "the infrastructure is slow" — they think the whole system is not ready, model included.
That is why rendering millions of rows in seconds was never a vanity metric for us. Virtualization, streaming updates, server-side shaping of data before it hits the wire — that frontend engineering is what makes the data science legible. A brilliant model behind an unresponsive UI is, operationally, a bad model.
3. Infrastructure as code is a kindness to your future self
In a regulated environment, "it works on my cluster" is not a deployment strategy. Everything — compute, queues, model endpoints, permissions — lives in version-controlled infrastructure definitions. The payoff is not ideological purity; it is that reproducing an environment, auditing a change, or unwinding a bad release becomes a pull request instead of an archaeology project.
4. Data scientists are your users too
The platform's real product is velocity for people who think in models, not in Kubernetes. Onboarding a data scientist should feel like being handed keys, not a second job. Templates, paved paths, documentation that answers the third question before it is asked — the platform succeeds when the people it serves ship without needing its builders in the room.
5. The boring disciplines compound
Monitoring that watches model inputs drift, not just CPU. Pipelines that fail loudly and specifically. Documentation written the week the system was built, not the week someone leaves. None of these makes a demo better. All of them decide whether the platform is still trusted a year later.
The romance in this work is not in the model — it is in the moment someone who will never read a line of your code makes a faster, better decision because the whole chain held: stream to pipeline to model to a grid that rendered before they finished their coffee. That chain is the product. The notebook was just the pitch.