AI Doesn't Scale Until You Stop Calling It Innovation

Most enterprises have a team that deals with AI. Fewer have AI fully operationalized. The gap between experimentation and enterprise-level deployment is where most organizations stall, cycling through proofs of concept that never reach the customer. The shift now underway is about the operating discipline to ship AI as a product.

Philippe Rambach is the Chief AI Officer at Schneider Electric, a global leader in energy management and industrial automation. The company's two core activities, technology for energy management and automating industrial operations, center on helping customers being more efficient by using fewer resources and less carbon-intensive energy across buildings, factories, homes, data centers, electrical grid, etc.

Schneider Electric uses Databricks as a key platform within its broader data and AI ecosystem, applying Databricks’ , unified data and AI capabilities to ingest and process high volumes of industrial telemetry, power machine learning at scale across multi-cloud environments, and enable natural-language data access through Databricks Genie. Philippe built the company's AI organization from the ground up. His team of 400 is split evenly between embedding intelligence into customer-facing products and improving internal operations at scale.

From Phillipe’s perspective, the companies successfully deploying AI at scale are the ones applying the same product development rigor they would to any other capability they ship, with gate reviews, portfolio management, and teams accountable for production.

What AI-native actually means

Aly McGue: As more organizations incorporate AI into their products, the line between a genuine AI-native application and a traditional product with intelligence layered on top can become blurred. How do you think about that distinction?

Philippe Rambach: The key point is that when AI is native, it is completely part of the application's value proposition. Without AI, the product either has no value or loses most of its value. We are not building something on top of the application. It is core to what the solution delivers.

Our customers' needs didn't really change with AI. They still want outcomes: better uptime, better energy efficiency, lower energy costs and better resilience. You could go to our install base and say, "You should buy this because it's new," and they wouldn't be that excited. The real shift is moving from bolt-on to AI-native, from "it's super exciting" to delivering core value: helping customers operate with less energy, cheaper energy and more decarbonized energy. That has to sit at the core of the solution, not alongside it.

Building for scale, not proof of concept

Aly: You've described AI-native as core to the product's value. What did it take, organizationally, to make that real across people, processes and platforms?

Philippe: On the people side, it comes back to the need to merge domain knowledge with AI knowledge. An AI team by itself will build super fancy things that look really good, what I call “shiny objects”, but not necessarily things that truly help customers. So, we created a hub-and-spoke model.

Each solution starts with a business case owned by the line of business. Then we form a scrum team in the pure agile sense with every resource needed to deploy at scale: AI experts, customer-facing people, IT integration, software developers from the business, sales training,pricing, etc. The team doesn't stop when they've proven technical feasibility or delivered one proof of concept. They stop when the solution is in production and moving into support.

On the platform side, if you really want to go AI-native at full speed in a company like ours, you cannot have thousands of different technical solutions. We established a team to define and maintain a single set of core technologies across the whole company. At any given moment, there is one platform. Databricks plays a key role in that. It manages the infrastructure, the data and the flow of data, so we can spend more time on the business logic and the problem to solve rather than low-level technical difficulties.

My strong belief is that companies should stop treating AI as innovation and start treating it as product development. I think this is the most important shift. We have a process with gate reviews just like any product, moving through ideation, exploration, incubation, industrialization, and operation. Between each phase, my counterpart on the business side and I decide whether it's technically ready, commercially viable, and whether the business plan holds before we move forward. On a quarterly basis, we revise the full roadmap and portfolio. We treat AI like any other product we ship. That's the difference.

Aligning teams around the business value of AI

Aly: With that many moving parts, how do you keep cross-functional teams aligned from the first business case through to production deployment?

Philippe: Starting from use cases and business value is the best way to align people. Instead of debating forever about which technology provider is best, we start from the customer's needs. In a well-managed company, that's what moves people.

The other thing I'd highlight is accountability structure. In many companies I've benchmarked, one team builds a proof of concept, and another is supposed to industrialize it. Those two teams have very different targets, and they end up misaligned. In our model, the same team owns the full journey—from ideation to deployment at scale. They may still build a proof of concept along the way, but they do so with the end state in mind. In other organizations, one group may focus on demonstrating something fun while another optimizes for scalability. When a single team is responsible for both, that tension disappears.

From requesting data to conversing with it

Aly: Databricks Genie gives non-technical users a natural language interface to query data directly. What shift are you seeing internally?

Philippe: One of the core challenges right now, especially in agentic solutions, is how you access the right information from your data when that data is increasingly unstructured. Genie is very promising on that front. It saves us time on core activities common across many customers, such as extracting data from a database in natural language.

Internally, Genie has just been released, so it's early. But the excitement is massive. People are tired of asking someone to run an analysis and getting back something an hour or a day later that isn't quite what they wanted. The ability to get data yourself in natural language is a huge improvement in how we work. We need to make sure we get enough accuracy, and we're working closely with Databricks on that. But the potential buy-in is very strong.

Why models alone aren't the answer

Aly: When so many powerful models are available externally, what's the case for building AI-native applications on your own data and infrastructure?

Philippe: We absolutely use external models. We don't develop our own language models; we use many of them. But a model by itself is never a complete solution. It needs context, guardrailing, user interfaces, sometimes a combination of classical analytical AI with large language models, sometimes multiple LLMs powering multiple agents making decisions on different bases. We build multi-agent systems in which agents sometimes compete rather than just collaborate.

Take our EcoStruxure™ Microgrid Advisor, for example. A customer has a few buildings, maybe a university campus, with solar panels and wind generation. We ingest all that site data at high frequency to accurately forecast energy production and demand. Then AI optimizes every 15 minutes based on the next 48 hours: is it better to use the power you're producing now, sell it to the grid, buy from the grid, or store it for tomorrow? That's not one model. That's forecasting, optimization, and real-time decision-making working together on the customer's own operational data. We see up to a 20 percent reduction in energy costs from solutions like that.

The models are available to everyone. What's not available to everyone is the domain-specific foundation you orchestrate them around. You need everything.

Advice for leaders starting this work

Aly: For leaders who are early in this work, what are the lessons you wish more organizations internalized before scaling AI?

Philippe: First, start with the business case, not with technology. Don't start from "there is a new thing from whatever supplier." Start with what you need to transform and how AI can help, so you can focus on impact at scale.

Second, train your people. The AI transformation will not happen if people don't have what I call an adult relationship with AI. It does wonderful things, but not everything. It's not as scary as some people think. You need to educate your teams on how to use it and its limitations.

Third, and probably the most provocative: don't forget everything you already know. When people start an AI project, they forget it's first a project. They forget it's first a transformation. Our company has learned for years how to manage change. A big part of an AI project is exactly that. Some parts need reinvention, but not everything.

Closing Thoughts

フィリップ氏が最も意図的に選択したのは、AIを特別なものとして扱わないことである。その計り知れない可能性においてではなく、どのように管理されるべきかという点においてである。ハブアンドスポークモデル、ゲートレビュー、単一プラットフォームへのこだわり、そしてエンドツーエンドのチームオーナーシップ。これらはAI戦略ではない。これらは、シュナイダーエレクトリックが顧客に出荷する他のどのような機能にも適用するのと同じ厳格さで適用される製品戦略である。

AIをイノベーション機能として、別個のチーム、別個のタイムライン、別個の説明責任で運用し続けている経営陣にとって、この挑発は検討に値する。AIを大規模に展開している企業は、最も創造的なプロトタイプを持つ企業ではない。イノベーションと呼ぶのをやめ、製品として出荷し始めた企業である。

25以上の業界リーダーから学び、AIを運用化する道筋を定義するには、Databricksが支援するEconomist Enterpriseによる「Making AI Deliver」をダウンロードしてください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事