The app is the deliverable now
Enterprise AI delivery moved from model inference to production applications. What that changes about who builds, what breaks, and what it takes to prove the work.
Across Rev London, Rev New York, and Rev Philadelphia, Domino’s conference proceedings highlighted a structural pivot: the unit of enterprise AI delivery shifted from model inference to production applications. Instead of deploying backend endpoints, teams now ship tailored tools directly to fraud analysts, biostatisticians, and media planners. What looks like a cosmetic shift actually reshapes who writes code, where infrastructure breaks down, and how governance must be built.
This shift fundamentally reorders three core pillars. The builder changes, as domain experts like biostatisticians now write production software requiring permission-focused guardrails. The failure mode shifts, as un-scoped infrastructure bottlenecks like write locks replace model quality as the main operational threat. And the proof burden evolves, demanding automated, environment-level audit trails rather than outdated chatbot review gates.
Predictive ML automated actions on numbers: scoring, classifying, and flagging. Generative AI extends that automation to language and judgment, expanding what software can actually do. By Domino's estimate, applying AI to human judgment made software ten times more capable, while AI coding assistants made building that software a hundred times faster [1]. Together, those two multipliers changed who builds software and what gets built.
"In the era of traditional predictive ML, the primary way of delivering AI solutions was with APIs and inference. And you deployed models, and those got integrated into these software systems. With generative AI, the primary modality for delivering AI now is apps."
Nick Elprin, Former CEO, CPO and President, Domino Data Lab [1].
The customer side arrives at the same place from its own direction. At Bristol Myers Squibb, a researcher can go from a raw data file to a deployed analytical application with a single natural-language prompt [2]. At WPP, planning teams interrogate audience segment data across dimensions without running code [3].
"The era of the dashboard is poised for change when anyone can take a CSV or an Excel file and spit out an interactive application."
Jacob Albrecht, Director, Intelligence Systems Lab, Bristol Myers Squibb [2].
The range of work is wide. Merck was moving statistical programmers off a 25-year-old Linux system with hand-maintained Excel audit trails [4]. AstraZeneca was running autonomous agents against patient data [5]. From statistical computing to agentic AI, and the constraints that turned up were the same at both ends.
What follows are five rules from enterprise teams running AI applications in regulated production.
Rule 1. Build the platform for domain creators, not just software engineers
The person building the application is often not a software engineer. A majority of coding assistant users do not identify as professional developers [1]. In a regulated enterprise, the people writing this software are quants, biostatisticians, risk analysts, scientists, and operations staff.
At AstraZeneca, a scientist built and deployed a generative AI application in a single afternoon without opening an IT ticket [5]. At Vevo, a seven-person data science team sitting inside Revenue Operations built an AI-powered programming automation tool that would previously have required an outside vendor [6]. At Bristol Myers Squibb, the argument is that the era of the dedicated dashboard developer is changing, because any practitioner can now deploy a production-quality analytical application from a data file and a prompt [2].
At the same time, incoming hires are raising expectations. Novartis, whose advanced quantitative sciences organization runs to 1,200 quantitative scientists, sees new graduates arrive with R, Python, and AI-assisted workflows already embedded in how they work [7]. They are not waiting to be trained, and organizations that cannot give them a compliant, high-velocity environment lose them.
For anyone designing an AI platform, this reorders the requirements. Your builders are domain experts with production access and no software engineering background. Guardrails, permissions, and environments must be built to fit those creators, making the compliant path the fastest way for a scientist to deploy software.
"The bottleneck was never technology or the model. It was permission."
Brian Dummann, VP, Head of Enterprise AI Technology, AstraZeneca [8].
Rule 2. Staff for the engineering that starts after the demo works
In regulated production, the failures that stall AI applications come from traditional software infrastructure rather than model drift. Post-mortems from enterprise deployments reveal two distinct engineering hurdles that emerge after a prototype succeeds: infrastructure stability and statistical defensibility.
At Helvetia Baloise, post-mortems on two production systems read as a list of ordinary software breakdowns: logging every inference request straight to a relational database created write locks under load, auth tokens appeared in log files, and a scheduled job died when a dependency update introduced an unwhitelisted proxy URL [9]. AI did not create these flaws; it simply magnified underlying system debt.
"Early demos really looked magical, but first production attempts hurt, because capability doesn't equal production readiness."
Thomas Reichert, Data Scientist, Helvetia Baloise [9].
Getting an answer from a language model is straightforward; making that answer defensible to a risk function requires traditional data science. When BNP Paribas Cardif built its Verbatim Analyzer, the engineering focus was on recalibrating confidence scores. The team fitted Platt scaling on human-annotated examples, ran Efron bootstrap resampling to attach confidence intervals, and shuffled input orders to eliminate position bias [10].
"Gen AI is the cherry, not the cake. Gen AI amplifies your system, but traditional AI is what makes it viable. About 90% of what's happening in our product is related to traditional AI."
Omar Souaidi, Applied AI Engineer, BNP Paribas Cardif [10].
A prototype does not inherently deliver reproducibility, observability, or auditability. While model capabilities have advanced, the gap between a working demo and a production system that a risk team will sign off on remains wide, and it must be budgeted for during initial project scoping.
"Toys are not tools. The technology problem was always solvable. The infrastructure required to deploy AI safely in a regulated context is the constraint."
Nick Elprin, Former CEO, CPO and President, Domino Data Lab [1].
Rule 3. Put model access behind one gateway before the model list grows
Controlling model access at the infrastructure layer is what makes multi-model governance tractable at scale, because the alternative is auditing every application separately.
AstraZeneca routes every AI call through a single gateway that handles auth, policy enforcement, audit, rate limiting, and routing across more than 75 approved models [8]. Underneath that sit more than 10 agents in production in R&D, more than 1,600 researchers active on agentic platforms, and reach to over 60,000 employees monthly across more than 100 countries.
Establishing this gateway early, while the approved model list is short, prevents the administrative paralysis of auditing applications individually.
Rule 4. Make the audit trail a by-product of the work
Governance run as a manual review step forces teams to assemble evidence retroactively. Gating new technology behind traditional approval boards breeds friction without adding safety, stalling pilots indefinitely. The solution is structural: embed compliance directly into the execution environment so the audit trail writes itself as work happens.
After six months of process building, an internal audit at AstraZeneca returned over a dozen findings, all of them caused by applying a chatbot-era governance review to autonomous agents [8]. The platform engineering team fixed this by establishing an immutable "scientific unit of work" that binds logic, data, and environment together [5]. Because the workspace was pre-qualified for production and wired directly to audit tools, choosing the model became the final step rather than the initial roadblock.
"Governance is the road, not a gate. Safe is the fast way."
Brian Dummann, VP, Head of Enterprise AI Technology, AstraZeneca [8].
Merck reached the same conclusion from the legacy side. Statistical programmers were trapped manually maintaining Excel audit logs on a 25-year-old Linux system, burning time on compliance that belonged to science. Shifting audit tracking into the underlying platform eliminated human error and manual overhead.
"Across all of this, over the years, we still do manual capture of audit trails... and it's growing old. We felt that compliance should be automated. We shouldn't spend time on compliance or capturing, it should be done by the system, and you should focus on science. So that was the breaking point."
Uday Kiran Reddy Kandula, Principal Scientist, Merck [4].
Fannie Mae attached concrete metrics to this model through its fnm-benchmark library. By automatically capturing retraceability anchors on every run, including the git commit hash, the environment revision, and the pipeline script path, a model project that historically took four months finished in six weeks with a review-ready evidence package [11].
However, building compliant infrastructure must be paired with early reviewer engagement. As UCB observed in its DELTA program, bringing QA and risk teams in at the outset turns reviewers into active partners, eliminating late-stage rework and approval delays [13].
Rule 5. Measure adoption by pattern reuse, not seat licenses
Standard platform metrics like user counts, compute spend, and data volumes can all climb without teams actually working together [2]. True platform maturity occurs when one team’s output becomes another team’s starting point [2, 3].
Enterprise teams close the gap between core platform capabilities and domain-specific needs by packaging repeatable workflows. WPP’s central data science team built a statistical data fusion pipeline and packaged it into a standardized workflow, allowing local market teams worldwide to run advanced methodologies for clients without rebuilding them. [3].
Novartis and KSM built purpose-built tools on top of platform APIs to eliminate manual trial setup, standardizing clinical computing across more than 1,000 quantitative scientists [12].
Bristol Myers Squibb explicitly turns this into an operational metric. Supporting 5,000 users and 30,000 projects across nine business units, BMS measures platform success by how frequently teams adopt established analytic patterns rather than how much compute they consume [2].
"Early in my career I would have a naive view of what scaling means. It's not just more users; people have to be reusing the patterns across teams. And it's not just more data, it's more decisions, because it only really exists to facilitate those decisions. Those decisions need to be trusted, and they need to earn that trust through reproducible workflows. And it's not just scaling up to have more compute, it's more adoption through our shared environments and standard analytic approaches."
Jacob Albrecht, Director, Intelligence Systems Lab, Bristol Myers Squibb [2].
Track how many teams adopt a pattern built elsewhere. Compute spend and license counts can grow indefinitely without delivering operational leverage.
Where the judgment sits now
Judgment used to fall on whether the model worked. It now falls on whether a claims adjuster can open the application and get an answer, and on whether anyone can reconstruct that answer eighteen months later.
None of the teams here got there by picking a better model. They changed who the environment was built for, staffed for the engineering that starts after the demo, put model access behind one control point, made the evidence a by-product of the work, and measured themselves on reuse.
Watch the sessions
Every session cited here is in the Rev on-demand library, with the full talk and the questions that followed: Rev 2026 on demand.
To work through what this means for your own environment, talk to an expert.
References
[1] Nick Elprin, CEO and Co-Founder, Domino Data Lab. "Welcome to the Apps revolution." Rev London, Rev New York, and Rev Philadelphia, 2026. Delivered in all three cities; the library carries one recording.
[2] Jacob Albrecht, Director, Intelligence Systems Lab, Bristol Myers Squibb. "Build, Measure, Scale: growing data science and applied AI at BMS." Rev Philadelphia, 2026.
[3] Adam Bailey, SVP, Head of Data Science, EMEA, WPP. "From infra to insight, a client intelligence platform to serve global brands." Rev London, 2026.
[4] Uday Kiran Reddy Kandula, Principal Scientist, Merck. "Evolving the statistical computing environment." Rev Philadelphia, 2026.
[5] Justin Lecher, Sr. Director, Data and Platform Engineering, AstraZeneca. "Low friction, high compliance: AstraZeneca enables scientists to move faster, together." Rev London, 2026.
[6] Rohan Ramesh, VP, Data Science, Vevo. "The force multiplier: AI, automation, and adoption." Rev New York, 2026.
[7] Eric Gibson, SVP, Global Head of Advanced Quantitative Sciences, Novartis. "View from the top: a conversation on AI's moment." Rev Philadelphia, 2026.
[8] Brian Dummann, VP, Head of Enterprise AI Technology, AstraZeneca. "From chatbots to multi-agent AI: AstraZeneca's unfiltered take." Rev Philadelphia, 2026.
[9] Thomas Reichert, Data Scientist, Helvetia Baloise. "AI in production, where it truly elevates and where it doesn't." Rev London, 2026.
[10] Omar Souaidi, Applied AI Engineer, BNP Paribas Cardif. "From data science to AI engineering: building LLM-powered apps." Rev London, 2026.
[11] Chris Porter, Data Science Advisor, and Rabbani Mozahid, Director, Fannie Mae. "Benchmarking at scale: accelerating model development in mortgage lending." Rev New York, 2026.
[12] Priya Subramaniam, Head of Dev, IT Clinical Enablement, Strategy and Growth, Novartis, with Mike Harnish, President and Managing Partner, KSM Technology Partners. "Inside the SCE journey, lessons from the field." Rev Philadelphia, 2026.
[13] Tim Williams, Statistical Solutions Lead, UCB. "Modernizing the SCE, more than a change of address." Rev Philadelphia, 2026.
