. THREE PRACTITIONER INSIGHTS .

01

We evaluated 6 platforms. Here's the question that decided it.

We spent two months evaluating AI/ML platforms, Dataiku, Azure ML, SageMaker, Vertex AI, and two niche players. Feature matrices. Benchmark tests. Vendor presentations. After all of that, the deciding question was surprisingly simple: "Which one can my team be productive on within two weeks without calling the vendor's support line?" That eliminated three options immediately. The fanciest platform is worthless if your team can't use it without a certification program. We chose based on time-to-productivity, not feature count. Eighteen months later, I'd make the same call.

02

The cost that actually blew our budget: it wasn't the LLM API.

Everyone fixates on token pricing when comparing LLM providers. Our API costs for the first year: roughly €35K. Our total cost of running AI in production, including prompt engineering time, human validation workflows, monitoring infrastructure, incident response, user training, and change management: roughly €380K. The API was 9% of the total spend. Nine percent. If your business case is built on token cost projections, you're optimizing the wrong variable. The expensive parts are the humans around the model, not the model itself.

03

I optimised the wrong infrastructure metric for nine months.

Our on-premise GenAI infrastructure has been live for nine months. The metric I was tracking obsessively: cost per token. We optimised aggressively, batching, quantisation, smart routing between the on-prem model and external APIs for non-sensitive workloads. Token cost dropped 31% from baseline. I was pleased with myself. Then I looked at the bill that actually mattered: GPU utilisation. Average across the quarter, 22%. Twenty-two percent. We bought capacity sized for a peak that happens four hours a day on weekdays, and we sit idle the other twenty hours of every day, plus weekends. The surprise wasn't technical. It was that I'd been optimising the wrong thing for nine months. Token cost is a function of model efficiency. GPU economics is a function of demand smoothing. They are different problems with different solutions, and I'd been treating one as a proxy for the other. We launched a sandbox tier last month, risk analysts and finance team members can run experiments in off-peak windows at no internal chargeback. Early signal in two weeks: utilisation moved from 22% to 38%, and four use cases surfaced that nobody had asked for because the cost barrier had disappeared. The lesson I keep relearning: idle capacity is not a saving. It is a marketing budget for AI use cases you haven't approved yet. Spend it deliberately.

- Two Use Cases -

→ WIN The prompt library that saved 30% of development time

This is one of our quiet wins. We had prompt sprawl, dozens of GenAI applications, each with prompts stored in Jupyter notebooks, Slack threads, and people's heads. When someone left the team, their prompts left with them. We built a simple prompt library: a Git repository with version-controlled prompts, tagged by use case, model version, and performance metrics. Every production prompt has a changelog and an owner. When we upgraded our base model, instead of scrambling to rewrite prompts, we systematically tested the existing library against the new model and updated what needed updating. Development time dropped 30%. But the real value was institutional memory, we stopped losing knowledge every time someone went on vacation.

→ LESSON "Avoid vendor lock-in" cost us €1.4 million in vendor overlap

A bank I advise pursued a multi-cloud AI strategy to maintain optionality, running workloads on both AWS and Azure, with experiments on GCP. The theory: avoid lock-in, maintain negotiating leverage. The reality after 18 months: three sets of tooling, three DevOps configurations, three teams with platform-specific expertise, and cloud costs 2.1x over budget. No workload was portable in practice because each relied on cloud-native services. They eventually consolidated to one primary cloud. The "optionality" they'd paid €1.4M to preserve was theoretical, nobody was ever going to migrate a production model between clouds. Pick one. Go deep. Negotiate hard on pricing. Use the money you save to build something useful.

◉ THE REGULATORY SIGNAL

[Written on June 20th.] With the Digital Omnibus on AI now formally adopted and published in the Official Journal, attention shifts to the obligations that did not move. DORA's third-party ICT risk regime is one of them, and it has been in force since January 2025. Here is the conversation most banks are still avoiding: if you are using a commercial LLM API - OpenAI, Anthropic, Mistral, Google - that provider is a third-party ICT service provider under DORA Article 28. That means contractual requirements under Article 30, exit strategies, register entries, and - for any system supporting a "critical or important function" - much heavier obligations including the right to audit. The cleanest operational test: if your LLM provider went dark for 48 hours, could you continue regulated operations without material impact on clients or reporting? If the answer is "we would have to take the system offline," that AI system supports a critical or important function and needs an exit strategy in writing, not a vendor commitment in a sales deck. What to do this month: produce a one-page DORA classification for every AI system that uses an external model provider. Function supported, criticality assessment, contractual gaps, exit plan, and the recovery time objective if the provider is unavailable. The CSSF asked two banks I know about exactly this in the last quarter. They will ask the rest of us. The answer "we are working on it" is not the answer that ends the conversation.