Skip to main content
PerspectiveRev
September 3, 2026 | 19 min read

The app is the deliverable now, lessons from Rev 2026

Enterprises at Domino's annual customer conference on what breaks between the demo and the audit

Andrea Lowe
Andrea Lowe
← Return to blog home

Across Rev London, Rev New York, and Rev Philadelphia, the unit of AI delivery changed. Teams that used to ship a model behind an API now ship an application that a named person opens and uses. The people building those applications are frequently not software engineers. They are biostatisticians, quants, risk analysts, and operations staff with production access and no background in the engineering practices that keep production systems standing up.

That shift moves the hard problems. Thomas Reichert of Helvetia Baloise walked an audience through write locks, leaked authentication tokens, a memory leak, and a scheduled job killed by a blocked transitive dependency. Omar Souaidi of BNP Paribas Cardif described the calibration and bias-correction work standing between a language model's output and a number a business owner can act on. Brian Dummann of AstraZeneca described an internal audit that returned more than a dozen findings, all of them traceable to a governance model built for chatbots rather than agents. The model was working in all three cases.

The teams furthest along stopped treating governance as a review step and built it into the environment, so the audit trail is produced by the work rather than assembled after it. This paper collects what those teams changed, and what they would tell a team starting now.

Shipping an application replaced shipping an endpoint

Across three cities, the unit of delivery moved.

In the previous era, shipping AI meant deploying a model that some other system called over an API. Speakers at all three Rev events described something different. They are shipping AI-powered applications that a named person opens and uses. A fraud analyst. A biostatistician. A claims adjuster. A media planner who has never written a line of code.

Nick Elprin opened each event with the same argument. Predictive ML automated actions on numbers: scoring, classifying, flagging. Generative AI extends that to work that runs on language and judgment. By his estimate, that made software roughly ten times more capable, and coding assistants made it roughly a hundred times faster to build [1]. Those two shifts together 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. Rev London [1].

The customer sessions arrived at the same place from their own side of the problem. Jacob Albrecht of Bristol Myers Squibb described a researcher going from a raw data file to a deployed analytical application with a single natural-language prompt [2]. Adam Bailey of WPP described a tool that lets 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. Rev Philadelphia [2].

The range of work on display was wide and the constraints at both ends were the same. 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]. We’re seeing that the constraints that turned up were the same at both ends, from statistical computing to agentic AI.

Your builders are biostatisticians with production access

The person building the application is no longer a software engineer.

Elprin told each audience that a majority of coding assistant users do not identify as professional developers [1]. The people writing this software are quants, biostatisticians, risk analysts, scientists, and operations staff.

The customer sessions put faces on that claim. Justin Lecher of AstraZeneca described a scientist building and deploying a generative AI application in a single afternoon, without opening an IT ticket [5]. Rohan Ramesh runs a seven-person data science team at Vevo, sitting inside Revenue Operations, and built an AI-powered programming automation tool that would previously have required an outside vendor [6]. At Bristol Myers Squibb, Albrecht argued 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].

Eric Gibson of Novartis, who oversees 1,200 quantitative scientists, pointed out where the pressure is coming from [7]. New graduates arrive with R, Python, and AI-assisted workflows already embedded in how they work. They are not waiting to be trained. Organizations that cannot give them a usable environment lose them.

For anyone designing a platform, this reorders the requirements. Your builders are domain experts with production access and no software engineering background, and the guardrails have to fit those people. Brian Dummann of AstraZeneca, describing what it took to get more researchers building agents, named the constraint.

"The bottleneck was never technology or the model. It was permission."
Brian Dummann, VP, Head of Enterprise AI Technology, AstraZeneca. Rev Philadelphia [8].

What broke after the demo

Teams that got something into production kept coming back with the same category of problem. Thomas Reichert of Helvetia Baloise was specific about it. He opened by warning the audience that he had come to deliver a post-mortem, then walked through what broke in two production systems [9]. Logging every inference request straight to a relational database created write locks and latency spikes under load. Authentication tokens turned up in log files. A pricing model kept crashing until a Grafana dashboard showed memory accumulating under sustained traffic. A scheduled job that had run for months died after a dependency update pulled in a transitive requirement that included a browser binary whose download URL was not whitelisted in the corporate proxy.

None of those are model failures. They are software engineering failures that AI made more visible, and Reichert's framing is that AI amplifies whatever it encounters. Discipline gets amplified. So does chaos.

"Early demos really looked magical, but first production attempts hurt, because capability doesn't equal production readiness."
Thomas Reichert, Data Scientist, Helvetia Baloise. Rev London [9].

Omar Souaidi of BNP Paribas Cardif reached the same conclusion from the other direction. His team built the Verbatim Analyzer to extract structured insight from customer and employee feedback [10]. Wiring a language model to a classification task was the easy part. The engineering was in making the output defensible.

A language model will report 90 percent confidence without that number meaning much. Souaidi's team fitted Platt scaling on 30 to 40 human-annotated examples per category, which recalibrates the model's stated confidence against how often it turns out to be right. They used Efron bootstrap resampling to attach a confidence interval to each result, so a business owner can see how far the number would move if the sample had been slightly different. And because a language model weights items differently depending on where they sit in a list, the team submitted the same set of comments in several shuffled orders and compared what came back, which corrects for that position bias. Without that work, the system produces numbers a business owner cannot act on.

"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. Rev London [10].

Elprin named what a prototype does not come with: reproducibility, observability, auditability, and governance [1]. These teams found the same list the hard way. The models have improved. The distance between a working demo and something a risk function will sign has not closed.

"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. Rev Philadelphia [1].

Audit trails the work produces while it runs

The teams furthest along stopped treating governance as a review step. Brian Dummann described what happened at AstraZeneca when the architecture shifted from chatbots to autonomous agents [8]. AstraZeneca now runs more than 10 agents in production in R&D, has more than 1,600 researchers active on agentic platforms, and reaches over 60,000 employees monthly across more than 100 countries. Every AI call routes through a single gateway that handles auth, policy enforcement, audit, rate limiting, and routing across more than 75 approved models. Controlling model access at the infrastructure layer is what makes multi-model governance tractable at that scale, because the alternative is auditing every application separately.

His argument is that the pharma instinct, which is to build an approval process in front of a new technology, produces fear where it was aiming for safety. Governance built as infrastructure lets scientists move freely inside safe boundaries. Governance built as a gate stalls the work at the pilot and never recovers the time it was supposed to save.

"Governance is the road, not a gate. Safe is the fast way."
Brian Dummann, VP, Head of Enterprise AI Technology, AstraZeneca. Rev Philadelphia [8].

Dummann also volunteered the uncomfortable part. AstraZeneca ran an internal AI audit after six months of process-building, expected it to go smoothly, and got back more than a dozen findings. All of them traced to a chatbot-era governance model.

Lecher described the mechanism underneath [5]. He calls it the scientific unit of work: data, environment, and logic bound together in an immutable form, so reproducibility and audit become structural properties of the system. That design is why the patient-data agent reached production in weeks. The development environment was already qualified for production use, already approved for the relevant data classification, and already wired to audit infrastructure. Choosing the model was the last step.

Uday Kiran Reddy Kandula of Merck made the same case from the failure side [4]. Merck's outgoing environment was a 25-year-old Linux system with manually maintained Excel audit trails, which meant programmers spent time on compliance overhead that should have gone to science. His conclusion was that compliance belongs to the system, because human error lives in the gap between separate tools. Merck's programmers did not believe automatic audit trails were real until they watched the system log artifacts without anyone touching it.

"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. Rev Philadelphia [4].

At Fannie Mae, Chris Porter and Rabbani Mozahid showed what this buys [11]. Their fnm-benchmark library captures three retraceability anchors on every run: the git commit hash at execution time, the Domino environment revision, and the file path of the pipeline script. A benchmark model project that historically took four months finished in six weeks with a review-ready evidence package, and a post-review revision requested by leadership was turned around in under a day. The pipeline wrote that evidence package while the work ran, and Fannie Mae wrote the pipeline.

Teams build the last mile, then lend it out

Teams built on top of the platform to close the distance between what it gave them and what their own users needed.

Priya Subramaniam of Novartis and Mike Harnish of KSM Technology Partners described QUANTA, a unified statistical computing environment serving over 1,000 users across hundreds of studies [12]. Their framing was that Domino is a foundation you build on and connect from, and KSM built four purpose-built tools against its APIs to close the gap between platform capability and Novartis's clinical and regulatory requirements. One of them, RA Creator, exists specifically to eliminate the inconsistency of manual study setup, which in a regulated environment carries a cost in audit findings as well as time.

Adam Bailey described WPP's version [3]. The central data science team built a statistical data fusion pipeline, then packaged it as a reusable Domino workflow that local market teams run for their own clients without rebuilding the methodology.

Albrecht defined the payoff. He argued platform adoption should be measured by how many teams borrow and build on each other's patterns, rather than by growth in users, data, or compute [2]. Bristol Myers Squibb runs 5,000 users across nine business units and 30,000 projects on shared infrastructure, and has produced over 80 peer-reviewed publications from it [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. Rev Philadelphia [2].

What to change before the next project

The changes brought up at Rev fall along the same three lines Domino organizes the platform around: what it takes to build an AI-powered application, what it takes to scale it to the business, and what it takes to govern it.

Build the guardrails for the people who will actually build.

Your builder is the biostatistician who will deploy something on a Thursday afternoon. Lecher's finding at AstraZeneca is that scientists circumvent guardrails when the compliant option is painful, and that well-trained people in well-designed environments have no reason to [5].

Staff the project for the engineering that starts after the demo works.

Reichert's failures were write locks, leaked tokens, a memory leak, and a proxy blocking a transitive dependency [9]. Souaidi's team spent its effort on calibration and bias correction, not on the model call [10]. That work does not disappear if you skip it. It shows up in production instead of in review.

Put model access behind one gateway before the model list grows.

AstraZeneca routes every AI call through a single point handling auth, policy, audit, and rate limiting across more than 75 approved models [8]. The alternative is auditing each application on its own, which works until the tenth one.

Move the compliance conversation to the front of the project.

AstraZeneca's patient-data agent reached production in weeks because the environment was qualified before the project started [5]. Tim Williams of UCB reported a related paradox from the DELTA program: QA teams brought in at the outset became active participants who reduced late-stage rework, while late-arriving reviewers introduced delay [13]. Dummann put it more bluntly. Get the foundation right first, then embed policy in the code.

Measure adoption by reuse, not headcount.

Albrecht's test is how many teams build on each other's patterns [2]. WPP packaged one fusion pipeline as a workflow local markets run for their own clients [3]. Novartis and KSM built against Domino's APIs rather than around the gaps [12]. Measure how many teams borrowed a pattern from elsewhere.

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.


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.

Andrea Lowe
Andrea Lowe

Andrea Lowe, PhD is the Product Marketing Director for Data Science, AI, and ML at Domino Data Lab, where she drives go-to-market strategy and technical content for the platform. Over seven years at Domino, she has worked across training, sales engineering, product, and customer success, building a deep understanding of what it actually takes to deploy AI in regulated industries. Before entering tech, she was a neuroscientist turned data scientist.

Domino platform

The enterprise platform to build, deliver, and govern AI

Watch the 15 minute on-demand demo to get an overview of the Domino Enterprise AI Platform.

Watch demo

In this article

  • Shipping an application replaced shipping an endpoint
  • Your builders are biostatisticians with production access
  • What broke after the demo
  • Audit trails the work produces while it runs
  • Teams build the last mile, then lend it out
  • What to change before the next project
  • Watch the sessions
Home
Watch Demo
Watch Demo
Domino's logo

Who is Domino?

Domino Data Lab empowers the largest AI-driven enterprises to build and operate AI at scale. Domino’s Enterprise AI Platform provides an integrated experience encompassing model development, MLOps, collaboration, and governance. With Domino, global enterprises can develop better medicines, grow more productive crops, develop more competitive products, and more. Founded in 2013, Domino is backed by Sequoia Capital, Coatue Management, NVIDIA, Snowflake, and other leading investors.

Watch Demo
  • Platform

      • AI infrastructure
      • Data management
      • AI workbench
      • MLOps
      • AI governance
      • FinOps
      • Pricing
      • Security & compliance
      • What's new
  • Solutions

    • Industries

      • Life sciences
      • Finance
      • Public sector
      • Retail
      • Manufacturing
    • Use Cases

      • Generative AI
      • Cost-effective data science
      • Self-service data science
      • Model risk management
      • Cloud data science
  • Learn

      • Events
      • Blog
      • Podcast
      • Courses and certifications
      • Data Science Dictionary
      • Documentation
      • Support
      • Demo hub
  • Company

      • About
      • Why Domino
      • Careers
      • News and press
      • Partners
      • Customers
      • Contact us

© 2026 Domino Data Lab, Inc. Made in San Francisco.

  • Do not sell my personal information
  • Privacy policy
  • Terms and conditions
  • Security
  • Legal