This content is password-protected. To view it, please enter the password below.

Password:

SAP intends to acquire Prior Labs, a research lab and provider of tabular foundation models for predictive AI on structured data, and Dremio, an open data lakehouse platform enabling high-performance federated queries across SAP and non-SAP sources without data movement.

Acquisition 1: Prior Labs: Betting on Tabular AI

Prior Labs will strengthen SAP’s predictive AI capabilities on structured/tabular enterprise data. Combining their SAP data with TabPFN, Prior Labs’ AI model, users can cover use cases like predictive maintenance, demand forecasting, customer churn, and cash flow analysis. SAP will back this innovation with an investment of more than €1 billion over the coming years. SAP aims to make classical AI, particularly for prediction tasks, more accessible for a wider range of organizations, following the examples of LLMs that made generative AI accessible for every organization and even consumers. ⁠⁠⁠⁠⁠⁠⁠⁠The co-founders and scientific advisors of Prior Labs (including renowned AI experts like Yann LeCun and Bernhard Schölkopf) will remain in place.

What Prior Labs Is

Prior Labs is a German AI research company founded by Frank Hutter, Noah Hollmann, and Sauraj Gambhir, headquartered in Freiburg with offices in Berlin and New York. Its core product is TabPFN, a Tabular Foundation Model (TFM): a class of machine learning model purpose-built for structured, tabular data, as opposed to unstructured text or images.

Unlike general-purpose large language models, TFMs are trained to reason statistically over tables, numbers, and structured data records. The model supports in-context learning: users supply data records at inference time and receive predictions immediately, without retraining. A conversational interface allows non-technical business users to interact with the model via natural language. Prior Labs’ research has been published in Nature, and TabPFN has accumulated over three million open-source downloads, indicating meaningful adoption in the data science community.

From a technical standpoint, TabPFN (Tabular Prior-data Fitted Network) is a Transformer-based foundation model that, unlike many classical data science approaches requires no manual training or tuning. It relies on in-context learning: training data is passed as context at inference time, and the model generates predictions in seconds, in a single forward pass. This fact and the natural language interface make it much more accessible for subject matter experts without deep data science knowledge on the aspect of methods and technical skills.

Its key limitations are inference latency (training and test data are processed together on each call) and memory constraints at scale, making other models architectures the better choice for high-volume workloads.

Why it is important

Tabular foundation models like TabPFN lower the barrier to predictive AI significantly: they remove the need for data science expertise in model training, tuning, and preprocessing, making it feasible for business users in finance, operations, or sales to run predictive analyses directly on their own data. The implication is a broader reach, not just more organizations using predictive AI, but more people within those organizations applying it to a wider range of business problems. The prerequisite shifts from data science skills to domain knowledge: understanding the business problem well enough to frame it becomes the critical capability.

BARC Assessment

Opportunities:

• A new category of enterprise AI: Existing data science methods work well on structured, tabular data but they require data preparation and expert skills. Large Language Models on the other hand are more accessible for everyone, but (without workaround like creating Python scripts) they are performing poor on data analysis or prediction tasks. This is exactly the gap that TabPFN closes: Predictive AI on tabular data, driven by subject matter experts. That way, more predictive AI projects can be realized, especially small-scale projects.
• Differentiation in the agentic AI race: Combining tabular models with LLMs enables Joule/BDC agents to deliver both predictions and human-readable explanations, which is hard for LLM-only stacks to match.
• Top talent + €1B+ investment signal: Keeping key scientific leadership and backing it with a investment commitment positions SAP in the race, which platform will lead the race when it comes to agentic AI on business processes.
• Defensible end-to-end stack: Tabular AI on top of federated data access (Dremio, BDC itself, BDC partnerships) and master-data governance (Reltio) makes SAP AI aspirations much more credible.

Risk and open questions

• Early-stage technology maturity: Tabular foundation models are still new; real-world robustness, accuracy across diverse enterprise datasets, and scaling behavior are less proven than established AutoML/classical ML.
• LLMs narrow the gap via code generation: LLMs can write the data science code for classical ML pipelines, making them cheaper and more accessible. This innovation may partially erode the accessibility advantage TabPFN claims over traditional approaches
• Agentic AI may crowd out adoption: For many SAP customers, agentic AI is the more immediate priority. Tabular prediction projects may struggle to compete for budget and attention in the short term, however compelling the technology.
• Roadmap overlap with SAP-RPT-1: SAP already developed its own tabular foundation model, SAP-RPT-1. How TabPFN and RPT-1 will coexist, converge, or differentiate going forward remains an open question.

Statements

• “We continue as an independent entity — same brand, same team, same mission, same open-source commitments — now with the resource envelope, data environment and deployment reach to attack research problems that previously sat outside what was feasible.” – Frank Hutter, Founder and CEO of PriorLabs
• “TabPFN’s appeal in the SAP context raises a fair question: how much of the bottleneck is the complexity of predictive AI, and how much is SAP’s historically restricted data access? Where data flows freely, LLM-assisted scripting already makes custom predictive models fast and cheap to build. And those model are on average more cost-efficient than transformer models.” – Florian Bigelmaier, Analyst, BARC

Implications for the Market

For SAP Customers

• Predictive AI for structured enterprise data becomes mainstream: Expert data science knowledge becomes less of a bottleneck to create predictions from semantically rich tabular data.
• Smarter, more capable Joule agents: Tabular models complement (rather than replace) LLMs. This way, they can make Agentic AI and AI chatbots built for and within the SAP platforms more accurate and actionable on enterprise data.
• Long-term roadmap confidence: SAP’s commitment of more than €1 billion over the coming years, paired with leading AI talent, signals serious, sustained investment and that SAP is willing to invest to be a strong partner in the AI race.

For Prior Labs Customers

• Massive scale-up in resources: SAP’s €1B+ multi-year investment gives Prior Labs far more funding, compute, and enterprise data access to accelerate development beyond typical startup constraints.
• Continued open-source availability: In a press and media session, Irfan Khan and Philipp Herzig underlined that the committment of both firms (Prior Labs, Dremio) to open source will be continued.

Acquisition 2: Dremio – Modern Lakehouse Architecture for SAP

Dremio will strengthen SAP Business Data Cloud with federated, query-in-place lakehouse capabilities built on Apache Iceberg, Apache Arrow, and the Polaris catalog. SAP aims to enable customers to run high-performance queries across SAP and non-SAP data without physical consolidation.

What Dremio Is

Dremio is a US-based data platform vendor specializing in open lakehouse architecture. Its platform is built natively on Apache Iceberg, the open table format that has become the de facto standard for large-scale analytical data storage, and Apache Arrow, a columnar in-memory data format optimized for fast query execution.

The platform’s key functional areas are: a serverless, elastic query engine capable of running analytical workloads across heterogeneous data sources without data movement or format conversion; and Apache Polaris, an open catalog based on the Apache Iceberg REST Catalog API, which provides a unified metadata and governance layer across multiple environments.

Dremio positions itself on low total cost of ownership and openness: customers are not required to consolidate data into a proprietary store. The platform scales automatically with query demand, which avoids fixed-capacity provisioning costs. Dremio has been a significant open-source contributor, maintaining stewardship roles across Iceberg, Polaris, and Arrow.

Why SAP Is Buying It

Irfan Khan (President and Chief Product Officer, SAP Data & Analytics) framed the Dremio acquisition around three functional pillars for a modern lakehouse architecture inside SAP Business Data Cloud:

1. Open Table Format foundation: SAP already supports Iceberg and Delta Lake formats for HANA Data Lake files. Dremio adds a proven, high-performance query engine on top of that storage layer: a meaningful step from format support to full query-in-place capability.
2. High-performance, low-TCO query engine: A serverless, in-memory columnar engine that queries data where it resides. SAP customers have repeatedly asked for cost-effective ways to combine data from SAP and non-SAP sources and Dremio could be a cornerstone here to resolve the need for physical data movement further.
3. Polaris Catalog: A universal catalog enabling governed access to data across the full customer landscape, from hyperscaler object stores to legacy on-premise databases.

A less openly discussed topic: SAP’s own product sprawl creates data friction long before non-SAP sources enter the picture. Customers combining SuccessFactors, Ariba, S/4HANA, Concur, IBP, BW, BDC,… regularly hit integration walls; especially between products that have been natively developed by SAP and others that have been acquired. Dremio’s federation layer could address that internal SAP-to-SAP gap, which may prove as valuable as any cross-vendor use case.

BARC Assessment

Opportunities

• Unified, federated data foundation for AI: Joule/BDC agents can query SAP and non‑SAP sources in place, reducing/avoiding data movement and speeding time-to-value for AI.
• Faster, lower‑TCO BW/BW-HANA modernization: Dremio’s federation can act as a transition layer into Business Data Cloud by being able to query BW data that has not yet fully migrated to BDC.
• Sovereign + regulated-industry expansion for Dremio: SAP has a proven track record of being able to deliver on strict residency/compliance requirements (as required by customers in finance, public sector, healthcare), e.g., via sovereign/SAP Cloud deployment options.
• Bridge to legacy landscapes: Federation into SQL Server, Oracle, and other on‑prem systems enables AI use cases without rip-and-replace or full consolidation first.
• Complementary to Reltio (MDM): Combining federation/query access with MDM + data quality strengthens SAP’s end-to-end “data fabric” narrative for BDC across complex multi-landscape environments.

Risk / Open Questions

• Customer confusion over BDC strategy With BDC, HANA, Dremio, plus partnerships with Databricks, Snowflake, and Fabric, customers face an increasingly complex menu of options.
• Dremio is a query layer, not SAP data liberation SAP data access has historically been restricted, and this acquisition is unlikely to change that by default. SAP will need to demonstrate that Dremio operates as a genuinely bidirectional capability. The risk: it becomes primarily an inbound layer, pulling non-SAP data into SAP, rather than an open gateway through which external systems can query SAP data in return.
• Integration execution risk Embedding Dremio alongside HANA as an additional engine, with SQL decomposition and pushdown, is technically demanding. Delivery delays could undermine the BW migration value proposition.
• Organizational and cultural integration No clarity yet on future organizational setup, leadership, or how Dremio will operate within SAP, while the corporate cultures differ significantly. Talent retention and product focus are at risk during the transition.
• Channel conflict with strategic partners Databricks, Snowflake, Microsoft Fabric, AWS, and BigQuery may perceive Dremio as a competitive threat inside SAP accounts, straining co-sell motions despite SAP’s “complementary” framing.
• Semantics SAP now distributes semantic capabilities across multiple layers: BDC’s harmonized data products, the SAP Knowledge Graph, Datasphere, BW, SAC, and now Polaris via Dremio. Each carries a form of business context. Customers will need clear guidance on which semantic layer is authoritative, and for which purpose.

Statements

• “Dremio enables SAP customers to access non-SAP data without the headache of a migration.” – Kevin Petrie, VP Research, BARC US

Implications for the Market

For SAP Customers

• Federated, query-in-place architecture: Dremio removes the need to physically consolidate data before deriving AI value, bridging SAP BDC, modern lakehouses and legacy on-premise systems.
• Open standards reduce lock-in: Especially the reinforcement of the support of Apache Iceberg will ensure that SAP customers invest in industry-standard rather than proprietary technologies.
• Accelerated BW/HANA migration and sovereign deployment: Dremio supports the path to Business Data Cloud, potentially lowering TCO, and enables sovereign cloud setups for regulated industries.
• Open roadmap questions: Customers building agents need clearer guidance on which data option to choose; SAP is expected to provide details at Sapphire in Orlando next week.

For Dremio Customers

• Continued open-source commitment: SAP has explicitly stated it will maintain Dremio’s open source engagement, so existing investments in Iceberg, Arrow, and Polaris remain safe.⁠⁠
• Stronger enterprise backing and investment: Becoming part of SAP brings scale, financial stability, and access to a large enterprise customer base. But it also introduces dependency on SAP’s strategic priorities.⁠⁠
• Uncertainty until closing: Organizational setup and detailed integration plans are still pending regulatory approval and post-close announcements.

For Competing Vendors (Databricks, Snowflake, etc.)

• Predictive AI / AutoML vendors face a new heavyweight: With €1B+ committed and top tabular AI talent (Hutter, Erickson, LeCun, Schölkopf), SAP raises the bar for DataRobot, H2O, and similar players in structured-data AI.⁠⁠⁠⁠
• Open table format becomes table stakes: Iceberg’s positioning as the “USB-C of data exchange” pressures Delta-centric and proprietary-format vendors to double down on interoperability.⁠⁠⁠⁠
• Federation/virtualization specialists (Denodo, Starburst, Trino) lose differentiation: SAP-native federation reduces the need for third-party query engines in SAP-heavy landscapes.⁠⁠⁠⁠
• Pressure on standalone lakehouse players (Databricks, Snowflake, Fabric): SAP now offers a credible, SAP-aligned lakehouse alternative. Partnerships continue, but customers gain a “default” option that may erode net-new wins inside SAP accounts.⁠⁠⁠⁠⁠⁠
• Sovereign cloud and regulated-industry providers gain a stronger SAP-aligned competitor: Dremio’s deployment in SAP Cloud and sovereign properties challenges niche EU/regulated-data vendors.⁠

BARC’s view on SAP’s Data + AI Platform Strategy

Taken together, the Prior Labs and Dremio deals reinforce a coherent move by SAP to evolve from a business application vendor into a vertically integrated data-plus-AI platform, closing important gaps that SAP has left open so far.

• Vertical integration of the data + AI stack: SAP is assembling an end-to-end platform: Open lakehouse (Dremio), tabular foundation models (Prior Labs), MDM and data quality (Reltio), and Joule agents on top of Business Data Cloud.
• Doubling down on open standards: Apache Iceberg, Arrow, Polaris, and open-source TabPFN signal a deliberate shift away from a “walled garden” toward interoperability with Databricks, Snowflake, Microsoft Fabric, and the hyperscalers.
• AI focused on structured enterprise data: Both acquisitions target SAP’s core territory (transactional, tabular business data) rather than chasing generic GenAI use cases already dominated by hyperscalers and LLM vendors.
• Federation over consolidation: A consistent “query data where it lives” philosophy lowers migration friction, accelerates BW/HANA modernization, and may even support sovereign and regulated-industry deployments.
• Talent and capital at scale: Multi-year, billion-euro commitments combined with the retention of leading scientific talent underline SAP’s intent to compete credibly with pure-play data and AI platform vendors.

The BARC Score Integrated Planning & Analytics (IP&A) 2026 makes two things clear:

• IP&A matters more as companies in volatile markets need to plan, analyze, and decide faster.
• Vendors are putting a stronger innovation focus on agentic AI.

So the question is not whether AI will be used in IP&A. It is where can it deliver measurable value first without undermining governance or control?

Thesis

Agentic AI will not turn IP&A into an autopilot. Its first impact will be in processes that still rely on manual, recurring microtasks and where clear guardrails can be set. And that works when the relevant data is available, with the necessary quality and history behind it to feed the AI.

Why many AI approaches in IP&A fail

IP&A processes make weak AI obvious quickly.

• High stakes: Forecasts, budget changes, and management reports are not a sandbox.
• Traceability: Who changed what, when, and why?
• Heterogeneous data: Actual and plan data, master data, hierarchies, comments, and workflows.

If these foundations are not clean, AI can still produce text, but it cannot make the process more reliable.

Where agentic AI can automate first without losing trust

The first use cases that hold up will not be the flashy ones. They will be the ones that take up time.

1) Finding and triaging anomalies

Agents can check in the background for:

• unusual movements in cost centers or products
• notable driver changes in the forecast
• unexpected deviations between plan, actuals, or the past

Agents do not deliver “truth.” They point people to the issues that need attention.

2) Preparing variance explanations

In FP&A, most of the time is not spent on calculations, but on communication.

Agentic AI can draft:

• initial hypotheses about variance drivers
• consistent wording across business units
• signs of data quality issues

Drafts are fine. Approval and publication stay with people.

3) Forecast support instead of forecast autonomy

Agents can generate suggestions for:

• alternative driver assumptions
• sensitivities for price, volume, FX, and headcount
• scenarios that would not be set up manually

The value comes when suggestions are explainable and treated as options, not as the result.

4) Workflow triggers and “next best action”

An agent can trigger tasks when defined thresholds are exceeded:

• start a review
• notify the owner
• require a comment
• start data loading and validation checks

It may be boring, but that is exactly why it works.

What should deliberately remain manual

Not every step in the IP&A process is suitable for automation, especially decisions with high risk:

• Strategic goals and prioritization: Whether growth or margin is more important is not a calculation. That remains a management decision.
• Materiality: Not every variance is automatically important. What matters for steering depends on the business context.
• Regulatory compliance: When planning, reporting, or forecasts touch regulatory requirements, clear human control is needed.
• Approvals: Agents can prepare suggestions. The final decision needs a person who is responsible for it.

The checklist for trustworthy agentic AI in IP&A

When a vendor sells agentic AI, these questions matter:

• Explainability: Why did the suggestion appear, and which data was used?
• Audit trail: What was generated, what was accepted, and by whom?
• Boundaries: What is the agent allowed to decide, and what is off-limits?
• Fallback: What happens when data is missing or uncertainty is high?
• Governance: How are prompts, rules, and models versioned and tested?

Agentic AI will not change IP&A through one big feature, but through many small automations.

If teams choose the first use cases well, they gain speed without losing control.

The BARC Score Integrated Planning & Analytics (IP&A) 2026 describes this gap clearly: many organizations present integrated planning and analytics as the target state, but few achieve it consistently in practice. Important analyses and checks on target achievement still require time-consuming data transfers between planning and analytics. Excel often becomes the bridge. That bridge comes at a cost: inconsistent logic, inconsistent data, and ultimately inconsistent trust.

Thesis

Most IP&A initiatives do not fail for lack of commitment. They fail because a “single source of truth” is not a tool decision. It is a decision about the data model, governance, and operating model.

What breaks first when the “single source of truth” does not hold

When IP&A does not work in practice, the same patterns show up again and again.

1) Master data remains fragmented

A unified platform cannot repair a fragmented foundation. If cost centers, product hierarchies, legal entity structures, and charts of accounts are not harmonized, planning and analytics drift apart. Business units then make local corrections. In practice, “local” often means a spreadsheet.

2) The planning model and the analytics model are not the same model

Many organizations may use one platform, but in effect they create two semantic layers:

• a planning model, optimized for write-back and workflow
• an analytics model, optimized for slice-and-dice, drill-down, and dashboards

If those layers are not managed together, one platform effectively becomes two systems.

3) Governance is treated as a document, not as a design

Governance becomes a set of documents instead of an operating system. The key questions are operational:

• Who is allowed to change driver logic?
• Who is allowed to change mappings?
• How are changes tested?
• How are changes rolled out?
• How are changes communicated?

If the answers are unclear, teams fall back on side calculations.

4) Performance problems create workarounds

Performance matters greatly for usability and adoption. If screens load slowly, calculations take too long, or reports are slow to refresh, work moves out of the platform. This is not “resistance to change.” It is rational behavior.

5) The organization remains siloed

IP&A requires integration across planning, analytics, and often other CPM processes. If planning sits in finance, analytics in IT or BI, and data management somewhere in between, the “single source of truth” becomes a coordination problem. Coordination problems create delays. Delays create shadow processes.

A pragmatic fix: coherence before coverage

Many organizations try to cover too much at once: strategy planning, FP&A, operational planning, analytics, dashboards, simulations, AI features. A more robust sequence is to build coherence first, then breadth.

Start with three priorities:

1) A centrally managed master data backbone

Ownership for master data must be clear. Stabilize hierarchies and definitions first, then expand scope.

2) A shared actuals/plan model for the most important management views

If actuals and plan are not represented in one consistent model, the most important comparison in management reporting becomes a permanent debate.

3) A change process that business users accept

The market is pushing toward self-service. Self-service only works when changes are safe. Safe changes mean:

• clear roles
• workflow
• test environments
• audit trails

One takeaway

If the “single source of truth” still consists mainly of exports and reconciliations in practice, the bottleneck is rarely the frontend.

The leverage point is the data model, governance, and clear accountability. Tools matter, but the operating model determines whether IP&A works in practice.

A team builds a computer vision model to detect surface defects on metal strips. In the lab, it performs brilliantly – 98% accuracy. They deploy it to the factory floor. Within a week, accuracy drops to 70%. Operators lose trust. They roll back to manual inspection.

What went wrong? Not the model. The architecture.

Changing lighting conditions, dust accumulating on sensors, equipment degradation, operators using tools in unexpected ways – none of this existed in the lab. The model was fine. Everything around it was not.

This story, shared by Dr. Nikita Golovko from Siemens at the DATA festival Online 2025, captures a truth that three very different speakers – from Siemens, Merck, and Google – independently confirmed across their sessions: reliable AI is just 20% about modeling. But what about the other 80 % ?

Three companies. Three industries. One conclusion.

Merck: GenAI for 31,000 Employees – What It Actually Takes

Dr. Harsha Gurulingappa leads GenAI infrastructure at Merck, a company operating across healthcare, life science, and electronics. Merck has deployed GenAI to over 31,000 active users. That is not a pilot. That is enterprise scale.

The foundation rests on three pillars: people, standardized operating models, and technology. None of these pillars is optional.

Three tiers of AI access

Merck structures its GenAI offering into three categories:

• Everyday AI – An enterprise assistant called “myGPT” accessible to every employee. The goal: reduce the entry barrier to zero. 31,000 active users have created 17,000 custom assistants for specific tasks.
• AI for data natives – A specialized platform (Palantir Foundry) for teams working with highly curated data from Merck’s internal data lake. Purpose-built for complex analytical use cases.
• Developer toolkit – A modular system where developers pick and choose from inferencing services, vector databases, MLOps, coding assistants, and agent frameworks. High flexibility for custom solutions.

This approach ensures that different personas are served best, making everything from business user enablement to scalable, efficient engineer-built AI agents possible.

Governance is not optional at 31,000 users

At this scale, governance becomes existential. Merck operates across five governance dimensions:

• Documentation – Every use case has documented purpose, owners, linked data, associated risks, KPIs, and timelines.
• Process and standards – Access management, change management, and release management follow defined protocols aligned with enterprise software standards.
• Security – Identity management, authentication protocols, VPC peering for third-party cloud systems, and machine-to-machine permission handling. Non-negotiable for a highly regulated organization.
• Transparency – Two-way: developers make their work discoverable for reuse; the platform makes consumption costs and artifact metadata visible to teams.
• Enablement – Training materials, guides, and multi-format training sessions. A complex tech stack only creates value if people actually understand how to use it.

The observability imperative

One point Gurulingappa stressed repeatedly: observability is not a nice-to-have. It is a critical component.

Observability means tracing every step of an LLM application – what data it accessed, what queries it ran, what the model returned, and how guardrails performed. Without this, you cannot evaluate, monitor, or improve. And you cannot prove compliance.

For hallucination management specifically, Merck will opt for recommends guardrails at every single transaction in a multi-step agent flow. Not just at the final output. Because one hallucination in step three of a seven-step process corrupts everything downstream.

Siemens: The 80/20 Rule of Industrial AI

Dr. Nikita Golovko’s opening story about the failed defect detection model was not an anecdote about bad luck. It was a deliberate illustration of a systematic problem: most AI failures in industrial settings are AI system architecture failures, not model failures.

His framework for reliable industrial AI covers five layers.

Layer 1: Smart data strategies at the edge

Before you build any model, you need reliable data. Golovko’s approach starts at the edge device, directly at the production line:

• Pre-processing – Sort out bad data with noise, bad lighting conditions, and corrupted inputs before it ever reaches a model.
• Quality gateways – Detect data drift, environmental drift, sensor faults, and camera issues in real time.
• Data contracts – Versioned schemas that can be validated, providing traceability and reproducibility.

The key insight: data quality is not a cloud problem. It is an edge problem. Fix it at the source.

Layer 2: Software engineering best practices for ML Ops

The core principle is straightforward: keep every component modular and independently replaceable. When the model is decoupled from everything around it, you can swap it out, update a data source, or change infrastructure without risking the entire system.

Golovko implements this through what he calls a hexagonal architecture. Adapters and API gateways sit between the model and its environment, each with a clearly defined role:

• Input adapters for camera feeds
• Output adapters for PLC commands and data storage
• A model replacement interface for safe deployments
• Metrics collection and telemetry interfaces
• Operator feedback interfaces

The result: no single change triggers a cascade of failures.

Layer 3: Edge-cloud split with a purpose

Inference happens on the shop floor – 50 milliseconds from image capture to PLC (Programmable Logic Controller) command. The operational use case requires such low latency levels. No cloud round-trip can achieve that. But training and retraining happen in the cloud, where compute resources are abundant.

The connection between edge and cloud is secured with signed artifacts, encrypted channels , and routing through firewalls. Security in industrial environments is not an afterthought – it is a constraint that shapes the entire architecture.

Layer 4: The closed feedback loop

Models in isolation drift. Environmental conditions change. Hypotheses that seemed correct during development prove incomplete. Golovko closes the loop through:

• Drift monitoring integrated into data pre-processing
• Continuous model performance monitoring against reference results
• KPI-based triggers for cloud retraining
• Operator feedback interfaces for relabeling and re-annotation

Without this loop, model performance degrades undetected.

Layer 5: Safe deployment through a smart model lifecycle

New models never go straight to production. Instead:

1. Shadow deployment – The new model runs in parallel with the existing one, processing the same data but making no decisions. Its performance is monitored.
2. Canary deployment – The new model starts making decisions, but only for a percentage of data.
3. Production – After both stages validate performance, the model replaces the existing one.

Every stage includes rollback mechanisms. And every model artifact is stored in a registry with full metadata and linked training datasets.

Golovko’s summary line stays with you: “AI success in industry is 80% architecture and 20% proper modeling. Let us start building for the factory floor, not for the laboratory.”

Google: Four Pillars of Trustworthy AI

Nitesh Singhal from Google approached reliability from a different angle – not industrial automation, but the fundamental challenge of hallucination in GenAI systems.

His framing was direct: “AI can be confident but wrong at the same time. It might say Einstein won an Oscar. These are not bugs. They are byproducts of how models work. And they are real business risks.”

He cited two concrete examples: a health tech company that issued a public apology after AI-generated false medical advice, and a law firm that cited cases in court that did not exist.

The four pillars

Singhal’s framework for trustworthy AI rests on four pillars:

1. Data quality – When training data no longer reflects the environment the model operates in, accuracy erodes, often without any visible signal. Many consumers did experience that first hand when they learned about cut-off dates of Large Language Models. Better data means better AI – and this requires active, ongoing data management.

2. Model selection – Not every model fits every task. Using a GPT-5 scale model for simple classification tasks is wasteful. Using a lightweight model for complex reasoning is dangerous. Balance performance, cost, and explainability.

3. Validation and guardrails – Testing responses against ground truth. Monitoring for anomalous outputs. Cross-checking with trusted sources. Guardrails are an important safety component in AI systems.

4. Human oversight – Humans in the loop for high-stakes outputs. Feedback loops that help models improve. Clear accountability through governance structures.

Practical strategies that work

Singhal moved beyond frameworks into specific techniques:

• RAG (Retrieval Augmented Generation) – Instead of relying on the model’s training data, retrieve facts from reliable sources before generating. This reduces hallucination by grounding outputs in verified information.
• Fine-tuning with domain-specific data – Specialize generic foundational models for specific industries. Finance, healthcare, and legal each require models trained on domain-relevant data to produce accurate results.
• Automated verification at inference time – Fact-checking systems that flag hallucinations, check logic, verify tone, and assess accuracy before outputs reach users.

The proof: a fintech case study

Singhal shared a concrete example. A fintech company built an AI assistant for financial advisors. The pilot version hallucinated so frequently that advisors stopped using it. The project was on the verge of being scrapped.

The turnaround involved four steps:

1. Building a curated, domain-specific knowledge database
2. Adding RAG to validate facts against that database
3. Fine-tuning the model specifically for financial content
4. Introducing human approval for high-stakes outputs

The results: 95% reduction in factual errors and 63% faster workflows. Financial advisors went from rejecting the tool to calling it their trusted co-pilot.

The Common Thread: Data Quality and Architecture First

Three speakers. Pharma, manufacturing, tech. Enterprise assistant, factory floor AI, financial advisor tool. Completely different use cases.

And yet they converge on the same fundamentals:

• Data quality is the foundation. Every speaker placed data at the base of their reliability stack. Merck embeds AI into its broader data ecosystem. Siemens starts with smart data strategies at the edge. Google names data quality as pillar number one. Without trusted data, no architecture, no guardrails, and no amount of model sophistication will produce reliable outputs.
• Product and system design determines success. The model is a component, not the system. How you deploy it, monitor it, secure it, and update it – that is what separates lab results from production value.
• Observability is non-negotiable. You cannot improve what you cannot trace. Merck traces every LLM transaction. Siemens monitors drift in real time. Google uses automated verification at inference time. Blindly trusting a model in production is a recipe for the kind of failures that make headlines.
• Humans remain in the loop. But the interaction mode may differ from use case to use case.. Merck has governance standards for every use case. Siemens builds operator feedback directly into the architecture. Google’s Nitesh Singhal mandates human oversight for high-stakes decisions.

What This Means for Your AI Strategy

If your organization is still treating AI as a model selection exercise, these three case studies suggest a recalibration.

The questions that matter are not “Which LLM should we use?” or “How do we fine-tune for our domain?” Those are important, but they account for roughly 20% of the work.

The questions that determine success are:

• How reliable is the data feeding our AI systems?
• What happens when a model starts drifting in production?
• Can we trace every step of an AI decision when something goes wrong?
• Who is accountable when an AI output is wrong?
• How do we deploy model updates without risking production stability?

Merck, Siemens, and Google have answered these questions. The frameworks they shared at DATA festival Online are not theoretical – they are running in production, at scale, today.

The gap between AI that impresses in a demo and AI that delivers value in production is not about better models. It is about better engineering. One step after the other. And the first one is about data.