I have seen this movie before.

A decade ago, at Tesla, our Finance team faced a data crisis. We had information scattered across accounting, supply chain and delivery systems, all disconnected, all using different structures. The engineering team was rightfully focused on Full Self-Driving (FSD) and manufacturing. So, we did what productivity-hungry teams always do: We built our own solution. We taught ourselves Structured Query Language (SQL), normalized the data with creative IF-THEN logic and created our own reporting database.

It worked beautifully. Until it became a governance nightmare. The VP of Engineering hated our siloed system with embedded business logic. We eventually handed it over to IT, but not before our workaround forced the company to finally resource a proper data team.

The pattern is always the same: Productivity-hungry teams build workarounds faster than the organization can govern them, and by the time leadership notices, the workarounds have become the infrastructure.

That was more than a decade ago. The pattern took years to unfold.

Today, I am watching the exact same dynamic play out in insurance and industries across the board, but compressed into months, not years. AI adoption is sprawling across organizations, led by the same productivity-hungry individuals, but without central platforms or governance. Leadership has not created space for safe experimentation, so adoption spreads like a city without a highway system. The difference? Back then, we were building SQL databases. In 2026, we are building AI agents. And the cost of fragmentation is exponentially higher.

What is AI sprawl?

AI Sprawl is what happens when the cost of building AI drops faster than an organization can govern it. Teams spin up models, agents and automations independently. Each one works in isolation. None of them connect. The result is fragmented data, drifting decisions and intelligent systems that quietly get abandoned.

It happens because execution has become cheap. Large Language Model (LLM) APIs, no-code tools and cloud infrastructure have made spinning up AI trivially easy. A claims team builds an automation to speed adjudication. Underwriting builds a model to assess risk. Customer service deploys a chatbot. Each initiative delivers local value. No single project looks like a problem.

But collectively, they create an ungovernable landscape.

Over the past 18 months, the GenAI acceleration intensified what IDC calls the GenAI scramble: scattered, fragmented and sometimes redundant applications launched by business-led initiatives without central oversight. Many organizations have fallen into what researchers describe as a productivity trap: Focusing on short-sighted value generation instead of scalability, which limits their ability to create reusable capabilities across departments.

AI sprawl is everywhere

A major property and casualty carrier recently invited us to speak with their innovation leadership about implementing process automation. We spoke with more than 10 key stakeholders across multiple lines of business and found more than a dozen different POCs and local solutions across claims intake, underwriting and fraud detection.

Six of them were solving overlapping problems. None shared data infrastructure. Two had been abandoned months earlier but were still running and still being billed.

This is not an outlier. It is the norm.

AI Sprawl persists because it is insidious, hiding in plain sight unless you look for it. Business units move fast, build independently and solve immediate problems. IT discovers shadow AI only when something breaks, when an audit is triggered or when a vendor renewal surfaces a tool, nobody knew existed. And this symptom multiplies as more innovative teams exist within the organization.

The 4 hidden costs of sprawl

AI Sprawl creates costs that compound over time, many of which are not visible in any single budget line. It results in a dangerous cascade of failures:

1. Governance becomes impossible. Companies cannot govern what they cannot see. When AI systems scatter across departments, audit trails fragment. Bias monitoring becomes inconsistent. Explainability standards vary by team.
2. Scaling stalls. Disconnected systems cannot integrate. Every new initiative starts from scratch instead of building on shared infrastructure.
3. Maintenance and redundant spending multiply. Teams that built AI to accelerate their work end up spending most of their time maintaining it. One carrier reported that 60% of their AI engineering capacity was devoted to maintaining existing tools rather than building new capabilities. Meanwhile, teams unknowingly pay for overlapping capabilities because nobody has a complete view of AI spending.
4. Talent drains away. The best AI engineers want to solve hard problems. When they are cornered into spending their time maintaining fragmented infrastructure, they walk out the door.

Why traditional governance fails

Seventy percent of large insurers are investing in AI governance frameworks. Yet only 5% have mature frameworks in place. This gap is not about commitment or resources. It is about a category mistake.

For the last two decades, enterprise software governance worked because the software itself worked a certain way. Systems were point solutions. A claims platform did claims. A policy admin system did policy admin. Each tool had a clear owner, a defined scope and a predictable boundary. Governance could wrap around the edges, through access controls, audit logs, change management, vendor reviews, because the edges were visible. We governed the perimeter because the perimeter was the product.

AI is not a point solution. It is foundational technology, closer to electricity or a database than to a piece of software. It does not sit inside a defined boundary; it flows across every process, every decision and every department that touches data. And because it flows, it cannot be governed at the perimeter.

This is why carriers applying the old playbook keep running in place. Policy documents, oversight committees and compliance checklists were designed to govern systems that stood still. AI does not stand still. It is built, modified, retrained and extended by the same teams it is meant to serve, often in the same week. By the time a governance committee reviews it, three more versions exist somewhere else in the organization.

The failure is not that carriers are governing AI badly. It is that they are governing it as if it were software, when it’s actually infrastructure. Infrastructure requires a different discipline: Shared foundations, common standards and the assumption that everyone will build on top of it. You do not govern electricity by reviewing each appliance. You govern it by standardizing the grid.

Until carriers make that shift, their frameworks will keep maturing on paper while sprawl compounds underneath.

3 questions every insurance CIO should be able to answer

If the failure of traditional governance is a category mistake, the first job of leadership is to check which category they are actually operating in. These three questions are not meant to produce tidy answers. They are meant to reveal whether you are still governing AI as software when you should be governing it as infrastructure.

1. Are you governing AI at the perimeter, or at the foundation?

Look at your current AI governance artifacts, such as the policies, the committees, the review processes. Are they designed to wrap around individual tools after they are built, or to set shared standards that every tool must be built on top of? Perimeter governance asks, “is this specific model compliant?” Foundational governance asks, “does every model in this organization inherit the same definitions, the same lineage and the same guardrails by default?” If your governance only kicks in at review time, you’re still treating AI like software. You’re already behind.

2. If you standardized one thing across your entire organization tomorrow, what would create the most leverage and why haven’t you?

Every carrier has a list of things they know should be standardized but have not been. Shared definitions for core entities. Common ways of handling unstructured inputs. A single source of truth for how decisions get logged. The question is not which item belongs at the top of the list; most CIOs already know. The question is what has been blocking the standardization: Is it political, budgetary, or organizational? Because that blocker, whatever it is, is also what is letting sprawl compound. Governance frameworks cannot fix what foundational decisions have been deferred.

3. When a new AI initiative launches next quarter, what will it automatically inherit from what already exists?

This is the real test. In a point-solution world, every new system is built fresh and governance is applied afterward. In a foundational world, every new system inherits shared standards, shared definitions, shared oversight before a single line of code is written. If the honest answer is “it will inherit nothing, and we will govern it after the fact,” then you do not have an AI governance problem. You have an AI foundation problem, and no amount of policy will close the gap.

The uncomfortable truth is that most carriers will answer these questions honestly and discover they are still operating from the old playbook. It is a signal that the work to be done is not more governance, but different governance, the kind that assumes AI is the ground floor, not the top floor.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Too many data modernization efforts begin with the platform. The conversation turns to replacing the underlying data environment, moving reporting workloads to the cloud or retiring legacy tooling. Those decisions matter, but in my experience, they are rarely what makes the work hard.

What makes the work hard is everything that has built up around the platform over time.

I have seen this most often in organizations that inherited legacy architecture through acquisition, accumulated technical debt through years of deferred investment or saw reporting logic and master data evolve without enough enterprise discipline. On the surface, the environment may still appear functional. Dashboards are still refreshing. Reports still go out. Teams still find ways to get numbers. But once the business begins to scale, the weaknesses become much harder to hide.

The warning signs usually appear before the platform itself becomes the problem. Different teams start using different numbers for the same KPI, critical reporting logic begins to live outside core systems and analysts spend more time reconciling data than interpreting it. New business units take longer to onboard, reporting changes become harder than they should be and, before long, the issue is no longer just the data platform. It becomes a broader problem of trust, scalability and control.

That is why too many modernization efforts are scoped too narrowly. Replacing the platform is only one part of the challenge. The real work is untangling years of logic, definitions and integration patterns that were never designed to scale together.

The platform is only one layer of the problem

One of the clearest lessons I have learned is that legacy data environments rarely fail in an isolated way. They fail by becoming harder to trust and harder to change.

In many environments, the data platform is carrying far more than data. It is carrying years of workarounds for things that source systems were never able to handle cleanly. Reporting logic ends up split across ETL jobs, SQL transformations, scripts, spreadsheets and side databases. Some of it was built quickly to solve immediate business needs. Some of it was necessary at the time. But over time, those decisions create duplicated logic, hidden dependencies and handoffs that become harder to govern every time the business changes.

The issue is not only technical debt in the traditional sense. It is also reporting debt, where inconsistent definitions and duplicated logic across reports make data harder to trust and maintain. KPI definitions evolve differently across functions. Business logic gets embedded in too many places. Teams build local workarounds to compensate for mismatched source data. The business keeps moving, but the data foundation falls further behind.

That is why I think CIOs need to treat modernization less like a platform replacement and more like an effort to restore architectural separation and control.

In practice, that means separating ingestion, transformation and reporting instead of allowing all three to collapse into the same layer. It means reducing the number of places where business logic can live. It means establishing a clear source of truth for key metrics before they show up in executive dashboards. It also means making sure master data is defined consistently enough that teams are not comparing duplicate records or conflicting definitions and assuming the platform is to blame.

Fit matters more than feature depth

Platform decisions are often misunderstood.

On paper, most modern data platforms are capable. They all promise scale, flexibility and performance. But in practice, the decision is rarely about capability alone. It is about fit.

In recent modernization work, I have seen firsthand that the wrong decision is not always choosing an inferior technology. More often, it is choosing a platform that introduces unnecessary complexity into an environment that is already fragmented.

That complexity shows up quickly in the form of another cloud to manage, another billing model to track, another toolchain to support, another integration layer to maintain, another set of skills to build and another governance surface to control.

Those costs do not always show up clearly in vendor comparisons, but they show up immediately in execution.

That is why I have become more disciplined about asking a different question. Not what is the most powerful platform on paper, but what choice best aligns with the operating model, capabilities and simplification goals of the enterprise.

There is no one-size-fits-all answer. For some organizations, a separate cloud native warehouse may make perfect sense. For others, a more unified platform approach is the better fit because it leverages current skills, preserves momentum and avoids duplicating effort inside an ongoing modernization program.

That distinction matters.

The goal is not to build the most theoretically flexible architecture. It is to build one where the organization can actually govern, extend and operate over time.

Master data is where credibility starts

Modernization does not become credible until master data starts to improve.

That is not a side effort. It is part of the foundation.

In many enterprises, the root problem is not just the reporting layer. It is the fact that core entities such as customers, products, suppliers and locations are still defined differently across systems. When that happens, every downstream discussion about trust, reporting consistency and AI readiness becomes harder than it should be.

One area where this becomes tangible is syndication and deduplication. In most legacy environments, the same customer, product or supplier exists multiple times across systems, often with slight variations in naming, attributes or hierarchy. Over time, teams build local workarounds to compensate, which only reinforces the fragmentation.

Deduplication is not just a technical exercise. It forces alignment to what defines a unique entity. Syndication operationalizes that alignment, ensuring that once data is standardized, it is consistently distributed across systems and downstream processes. Without both, organizations end up maintaining multiple versions of the same truth and the platform becomes harder to trust regardless of how modern it is.

That is why I keep coming back to master data discipline. If important reports are not built on agreed business definitions and trusted logic, leaders end up looking at different versions of the same KPI. If customers, products and suppliers are not defined consistently across the business, the platform may look modern while the reporting remains hard to trust.

That is also why phased execution matters. Master data does not have to be fully resolved upfront, but it does need to be mature enough in the right domains to support the first releases and give the organization a foundation it can extend with confidence.

A modern foundation has to be engineered for change

What has worked best in my experience is a disciplined architecture that separates ingestion, transformation and reporting instead of mixing them together in ways that are hard to maintain.

That is where the medallion model becomes practical, giving the organization a structured way to separate raw data, standardized data and business-facing reporting. Bronze is where data first comes in from different systems. Silver is where it gets standardized, so the business is not working from conflicting definitions or duplicate records. Gold is where reporting and KPIs can sit on a more trusted foundation. That separation makes the environment easier to scale, troubleshoot and govern over time. The value is not in terminology, but in the discipline behind it.

I have seen organizations modernize into cloud data warehouses, data lakes and lakehouse architectures. The pattern is the same. If the underlying logic, master data and governance are still fragmented, the new platform inherits the same trust problems as the old one.

That same discipline has to carry through to the platform itself. If the environment is going to hold up under growth, the pipelines have to be observable, versioned and resilient enough to support change without constant rework. Environment separation, CI/CD workflows and operational monitoring are not extras. They are part of what makes the platform sustainable.

I also would not lead a modernization effort with AI, even when the pressure is high. AI raises the stakes, but it does not change the core problem. If the data foundation is still fragmented, poorly governed or inconsistent, a new AI layer will not solve it. That is increasingly showing up in the market, with Gartner warning that many generative AI efforts will stall because of poor data quality, inadequate risk controls, escalating costs or unclear business value. Foundry’s latest AI research reinforces this, identifying data storage and management as a top foundational investment for internal AI.

Final thought

The technology will continue to evolve.

The organizations that benefit most will not be the ones chasing every new platform. They will be the ones making disciplined decisions about how those platforms fit into their operating model and executing against them consistently.

Modernization does not fail because the technology is not good enough.

It struggles when the decisions behind it are not grounded in how the business actually runs.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

오픈텍스트에 따르면, 최근 국내 제조, 방산, 에너지, 공공기관을 중심으로 디지털 전환이 확대되면서 기술 문서와 운영 데이터 관리의 복잡성이 커지고 있다는 지적이 나온다. 특히 설비 유지보수(MRO) 환경에서는 데이터가 여러 시스템에 분산돼 있어 현장 엔지니어가 필요한 정보를 신속하게 확보하기 어렵다는 점이 과제로 언급된다.

또한 국내 기업들은 높은 보안 요구사항과 폐쇄적인 IT 환경 등의 이유로 클라우드 및 AI 도입에 신중한 태도를 보이고 있으며, 이 과정에서 데이터 활용도가 제한되는 이른바 ‘정보 사일로’ 현상이 발생하고 있다는 분석도 제기된다.

오픈텍스트와 원얼라인드는 이러한 문제를 해결할 수 있는 사례 중 하나로 미 해군 프로젝트를 소개하며, 폐쇄형 환경에서도 AI 기반 데이터 활용 가능성을 검증했다고 설명했다.

미 해군은 대규모 부품과 복잡한 유지보수 체계를 운영하는 과정에서 기술 문서와 데이터가 여러 시스템에 분산돼 있어 정보 활용과 정비 효율성 측면의 과제를 안고 있었다고 설명했다. 이에 오픈텍스트의 AI 기반 콘텐츠 관리 솔루션을 적용해 분산된 정보를 통합하고, 엔지니어가 필요한 데이터를 보다 신속하게 확인할 수 있는 환경을 구축했다고 밝혔다. 

오픈텍스트는 해당 솔루션이 데이터를 단순 저장하는 데 그치지 않고, 여러 시스템에 분산된 정보를 연결·구조화해 현장에서 활용할 수 있는 형태로 제공한다고 설명했다. 이를 통해 유지보수 작업 과정에서 필요한 정보 접근성을 높이고, 작업 효율 향상에 도움을 줄 수 있다는 것이다. 또한 AI 기반 분석 기능을 활용해 향후 필요한 정비 수요를 예측할 수 있도록 지원한다고 덧붙였다.  

오픈텍스트 관계자는 “국내 기업들도 AI 도입을 확대하고 있지만, 여전히 데이터가 분산되어 있어 실제 업무 혁신으로 이어지지 못하는 경우가 많다”며 “AI 콘텐츠 관리는 이러한 데이터를 연결해 실행 가능한 인사이트로 전환하는 핵심 기반”이라고 밝혔다. 

이어 “이번 미 해군 사례는 높은 보안성과 복잡성을 요구하는 환경에서도 AI 기반 정보 관리가 실질적인 성과로 이어질 수 있음을 보여주는 사례”라며 “국내 기업들도 이를 참고해 보다 현실적인 AI 활용 전략을 수립할 필요가 있다”고 설명했다.
dl-ciokorea@foundryco.com 

Oracle plans to issue security patches for its ERP, database, and other software on a monthly cycle, rather than quarterly, to respond to the increased pace of AI-enabled software vulnerability discovery.

Other software vendors, notably Microsoft, SAP, and Adobe, already release patches on a monthly beat, always on the second Tuesday of each month.

Oracle, though, is taking an off-beat approach: It will release the first of its monthly Critical Security Patch Updates (CSPUs) on May 28, the fourth Thursday, and after that, it will release its patches on the third Tuesday of each month — a week after the other vendors — with the next batches arriving on June 16, July 21, and August 18, it said earlier this week.

The new CSPUs “provide targeted fixes for critical vulnerabilities in a smaller, more focused format, allowing customers to address high-priority issues without waiting for the next quarterly release,” Oracle said.

It will issue a cumulative Critical Patch Update each quarter, so on the same schedule as before. The first one this year came in January.

Oracle initially announced the switch to a monthly patching schedule last week, but did not provide the dates.

The new patching rhythm will primarily interest customers running Oracle applications on premises or in their own or third-party hosting environments. For customers using the software in an Oracle-managed cloud, Oracle applies the patches automatically automatically.

Oracle is using artificial intelligence to identify and fix the vulnerabilities faster than before. It said it has access to OpenAI’s latest models through that company’s Trusted Access for Cyber program, and to Anthropic’s Claude Mythos Preview.

Mythos has contributed greatly to concerns that AI will uncover thousands of zero-day flaws in software, but as of mid-April, only one vulnerability report had been tied directly to it.

This article first appeared on CSO.

What is data analytics?

Data analytics focuses on gleaning insights from data. It comprises the processes, tools, and techniques of data analysis and management, and its chief aim is to apply statistical analysis and technologies on data to find trends and solve problems. Data analytics has become increasingly important in the enterprise to shape business processes and improve decision-making and business results.

Data analytics draws from a range of disciplines, including computer programming, mathematics, and statistics, to perform analysis on data in an effort to describe, predict, and improve performance. So to ensure robust analysis, data analytics teams leverage a range of data management techniques, including data mining, data cleansing, data transformation, data modeling, and more.

What is AI data analytics?

AI data analytics is a rapidly growing specialty within data analytics that applies AI to support, automate, and simplify data analysis. It leverages ML, natural language processing, and data mining, along with foundational models and chat assistance for predictive analytics, sentiment analysis, and AI-enhanced business intelligence. AI tools can be used for data collection and data preparation, while ML models can be trained to extract insights and patterns.

The four types of data analytics

Analytics breaks down broadly into four types: descriptive analytics attempts to describe what has transpired at a particular time; diagnostic analytics assesses why something has happened; predictive analytics ascertains the likelihood of something happening in the future; and prescriptive analytics provides recommended actions to take to achieve a desired outcome.

To explore these more specifically, descriptive analytics uses historical and current data from multiple sources to describe the present state, or a specified historical state, by identifying trends and patterns. Business analytics is the purview of business intelligence (BI). Diagnostic analytics uses data, often generated via descriptive analytics, to discover the factors or reasons for past performance. Predictive analytics applies techniques such as statistical modeling, forecasting, and ML to the output of descriptive and diagnostic analytics to make predictions about future outcomes. Predictive analytics is often considered a type of advanced analytics, and frequently depends on ML and/or deep learning. And prescriptive analytics is another type of advanced analytics that involves the application of testing and other techniques to recommend specific solutions that will deliver outcomes. In business, predictive analytics uses ML, business rules, and algorithms.

Data analytics methods and techniques

Data analysts use a number of methods and techniques to analyze data. According to Emily Stevens, managing editor at CareerFoundry, seven of the most popular include:

1. Regression analysis: A set of statistical processes used to estimate the relationships between variables to determine how changes to one or more might affect another, like how social media spending might affect sales.
2. Monte Carlo simulation: A mathematical technique, frequently used for risk analysis, that relies on repeated random sampling to determine the probability of various outcomes of an event that can’t otherwise be readily predicted due to degrees of uncertainty in its inputs.
3. Factor analysis: A statistical method for taking a massive data set and reducing it to a smaller, more manageable one to uncover hidden patterns, like when analyzing customer loyalty.
4. Cohort analysis: A form of analysis in which a dataset is broken into groups that share common characteristics, or cohorts, for analysis like understanding customer segments.
5. Cluster analysis: A statistical method in which items are classified and organized into clusters in an effort to reveal structures in data. Insurance firms might use cluster analysis to investigate why certain locations are associated with particular insurance claims, for instance.
6. Time series analysis: A statistical technique in which data in set time periods or intervals is analyzed to identify trends over time, such as weekly sales numbers or quarterly sales forecasting.
7. Sentiment analysis: A technique that uses natural language processing, text analysis, computational linguistics, and other tools to understand sentiments expressed in data, such as how customers feel about a brand or product based on responses in customer forums. While the previous six methods seek to analyze quantitative or measurable data, sentiment analysis seeks to interpret and classify qualitative data by organizing it all into themes.

Data analytics tools

Data analysts use a range of tools to aid them surface insights from data. Some of the most popular include: 

• Apache Spark: An open source data science platform to process big data and create cluster computing engines. 
• AskEnola AI: A conversational analytics tool for business users.
• Data analysis with ChatGPT: OpenAI’s chatbot can generate code to perform data analysis, transformation, and visualization tasks using Python.
• dbt: An open source analytics engineering tool for data analysts and engineers.
• Domo Analytics: A BI SaaS platform to gather and transform data.  
• Excel: Microsoft’s spreadsheet software for mathematical analysis and tabular reporting. 
• Julius AI: An AI assistant to analyze spreadsheets and databases.
• Knime: A free and open source data cleaning and analysis tool for data mining.
• Looker: Google’s data analytics and BI platform. 
• MySQL: An open source relational database management system to store application data used in data mining.
• Observable: A data analysis platform with AI tools for exploratory data analysis and data visualization.
• Orange: A data mining tool ideal for smaller projects.
• Power BI: Microsoft’s data visualization and analysis tool to create and distribute reports and dashboards. 
• Python: An open source programming language popular among data scientists to extract, summarize, and visualize data. 
• Qlik: A suite of tools to explore data and create data visualizations. 
• R: An open source data analytics tool for statistical analysis and graphical modeling. 
• RapidMiner: A data science platform that includes a visual workflow designer. 
• SAS: An analytics platform for business intelligence and data mining. 
• Sisense: A popular self-service BI platform. 
• Tableau: Data analysis software from Salesforce to create data dashboards and visualizations.

Data analytics vs. data science

Data analytics is a component of data science used to understand what an organization’s data looks like. Generally, the output of data analytics are reports and visualizations. Data science takes the output of analytics to study and solve problems. The difference between data analytics and data science is often about timescale. Data analytics describes the current or historical state of reality, whereas data science uses that data to predict and/or understand the future.

Data analytics vs. data analysis

While the terms data analytics and data analysis are frequently used interchangeably, data analysis is a subset of data analytics concerned with examining, cleansing, transforming, and modeling data to derive conclusions. Data analytics includes the tools and techniques used to perform data analysis.

Data analytics vs. business analytics

Business analytics is another subset of data analytics. It uses data analytics techniques, including data mining, statistical analysis, and predictive modeling, to drive better business decisions. Gartner defines business analytics as solutions used to build analysis models and simulations to create scenarios, understand realities, and predict future states.

Data analytics examples

Organizations across all industries leverage data analytics to improve operations, increase revenue, and facilitate digital transformations. Here are three examples:

UPS transforms air cargo operations with data, AI: UPS’s Gateway Technology Automation Platform (GTAP) uses AI and digital asset tracking to reduce costs, improve on-time performance, and enhance operational safety at its Worldport air hub.

NFL leverages AI and predictive analytics to reduce injuries: The NFL’s Digital Athlete platform leverages AI and ML to run millions of simulations of in-game scenarios, using video and player tracking data to identify the highest risk of injury during plays, and develop individualized injury prevention courses.

Fresenius Medical Care anticipates complications with predictive analytics: Fresenius Medical Care, which specializes in providing kidney dialysis services, is pioneering the use of a combination of near real-time IoT data and clinical data to predict when kidney dialysis patients might suffer a potentially life-threatening complication called intradialytic hypotension (IDH).

Data analytics salaries

According to data from PayScale, the average annual salary for a data analyst is $70,384, with a reported range from $51,000 to $95,000. Salary data on similar positions include:

JOB TITLE	SALARY RANGE	AVERAGE SALARY
Analytics manager	$79,000 to $140,000	$110,581
Business analyst, IT	$58,000 to $114,000	$80,610
Data scientist	$73,000 to $145,000	$103,441
Quantitative analyst	$74,000 to $161,000	$109,421
Senior business analyst	$72,000 to $127,000	$95,484
Statistician	$61,000 to $139,000	$97,082

PayScale also identifies cities where data analysts earn salaries that are higher than the national average. These include San Francisco (24.2%), Seattle (10.2%), and New York (9.5%).

The question nobody is asking loudly enough

I keep hearing the same AI conversation everywhere I go. Better models, faster inference, more capable agents. The race is on and everyone wants in.

But something is missing.

Most organizations I work with have already moved past experimentation. AI is embedded in workflows, shaping customer interactions, processing internal documents, informing operational decisions. The question of whether AI works has largely been answered. What has not been answered, in most cases, is something far more basic.

Where does our data actually go when it flows through an LLM? Who can access it? Under which jurisdiction is it processed? Could it end up improving someone else’s model?

These are not hypothetical concerns. These are the questions that surface when a regulator asks how your organization handles personal data, when a client wants to know what happens to the documents they share with your AI-powered service, or when a board member reads about a policy change at one of the major AI providers and wants to know what it means for the business.

In my experience, most organizations cannot answer these questions clearly. Not because they do not care, but because the adoption moved faster than the governance. Teams were encouraged to experiment, pilots became production and somewhere along the way, the data conversation got left behind.

This is not a fringe problem. Recent industry data suggests that most enterprise leaders are now actively redesigning their data architectures, not because the AI did not work, but because the way it was connected to their data became a liability.

The capability conversation has dominated for the last two years. I think the next two years will be defined by a different question entirely: Not what can AI do, but who controls what it knows?

Your data is already travelling further than you think

When I talk to CIOs about AI risk, the conversation almost always starts with model accuracy, hallucinations or bias. Rarely does anyone open with: “Do we actually know where our data goes when someone on the team uses an LLM?”

That question matters more than most people realise. Not because of some hypothetical future breach, but because right now, most organizations are operating across a mix of LLM tiers and tools with no unified picture of what data is going where or under what terms.

OpenAI, Anthropic and Google all operate a two-tier system. At the enterprise and API level, based on publicly available policies, the commitments are clear: Your data is not used for model training. But those protections only apply if everyone in your organization is using the enterprise tier. In practice, that is almost never the case.

Teams sign up for free accounts to test things quickly. Employees paste internal documents into consumer-tier tools because it is faster than raising a ticket. Contractors use personal subscriptions for client work. None of this is malicious. All of it is invisible to leadership.

And the consumer tiers operate under very different rules. OpenAI’s consumer ChatGPT may use conversations for model improvement unless the user opts out. Google’s free Gemini tier works similarly. In September 2025, Anthropic introduced changes to its consumer terms: Conversations are now eligible for training by default, with data retention extending from 30 days to up to five years.

This is the shadow AI problem. Corporate data entering consumer-tier systems where it may be retained for extended periods and processed under terms nobody in the organization approved. Not because anyone made a bad decision, but because no one made a deliberate one.

When a regulator in Riyadh asks how your organization handles personal data processed through an LLM, or a client in Doha wants to know where their documents went after your team used AI to summarise them, “we think we are on the enterprise tier” is not a defensible answer. The problem is not that something has gone wrong. It is that most organizations could not prove things are going right.

The sovereignty map is more complicated than people think

Most conversations about data sovereignty still default to one question: Where is the data stored? In the context of AI, that is not enough.

I work across the UK, the Gulf and Europe. Each region is moving toward stronger data protection, but they are getting there differently, at different speeds and with different expectations. For any organization operating across borders, that creates real tension.

In Europe, GDPR set the foundation and the EU AI Act is raising the bar further. In Saudi Arabia, the PDPL is no longer a paper exercise. SDAIA issued 48 enforcement decisions in 2025 and published cross-border transfer rules requiring a four-step risk assessment before personal data leaves the Kingdom. In Qatar, the PDPPL has been in place since 2016, but enforcement was historically light. That changed in late 2024, with the National Data Privacy Office now issuing binding decisions against organizations found in violation.

Now add the LLM layer.

When an organization sends data through a cloud-based LLM, the question is not just where the data is stored. It is where the data is processed at inference time. Your infrastructure might sit in Riyadh, but if the model processes your prompt on a server in another jurisdiction, most legal frameworks would say sovereignty has not been preserved.

And as organizations move toward agentic AI, this gets harder still. Agents do not respond to a single prompt. They retrieve context from multiple sources, call external tools and chain decisions across systems. Each step is a potential jurisdiction question and a potential compliance gap that nobody mapped.

Sovereignty is not just geography. It has at least four dimensions: Where data and compute reside, who manages them, who owns the underlying technology and who governs it. Most organizations are only thinking about the first one.

The real trade-off: Pay to keep your data or pay with your data

Once an organization recognises the sovereignty problem, the natural instinct is to bring everything in-house. Run your own models, keep your data on your own infrastructure, remove the dependency on external providers entirely.

That instinct is understandable. It is also expensive.

Local models like Llama and Mistral give you full control. No data leaves your boundary. No third-party terms to worry about. No inference happening in a jurisdiction you did not choose. On paper, it solves the problem.

In practice, a production-grade on-premise deployment for a 70 billion parameter model costs anywhere from $40,000 to $190,000 in hardware alone. Self-hosting only becomes cost-effective if you are processing above roughly two million tokens per day. Below that, the API is cheaper. On top of the hardware, you need the talent to deploy, fine-tune, secure, patch and maintain these systems over time. That is not a one-off cost. It is an ongoing operational commitment that most organizations underestimate.

And there is a capability gap. The frontier models, the ones that perform best on complex reasoning, coding, analysis and multi-step tasks, are not available for self-hosting. If your use case demands the best available performance, you are using an API. That means your data is leaving your boundary, processed under someone else’s terms, in someone else’s infrastructure.

So, the trade-off is real. At the extremes, you are either paying serious money to keep your data close, or you are paying with your data by accepting terms you may not fully understand. Most organizations sit somewhere in between, but very few have made that choice deliberately. It happened by default. Someone picked a tool, someone else signed up for an account, a pilot became production and suddenly the organization is operating across a patchwork of tiers, agreements and jurisdictions that nobody designed and nobody fully controls.

This is not a technology decision. It is a strategic one. And it belongs in the boardroom, not buried in an IT procurement process.

The market is already restructuring around sovereignty

If you want to know where enterprise AI is heading, follow the money.

The sovereign cloud market is projected to grow from $154 billion in 2025 to over $800 billion by 2032. That is not a forecast driven by hype. It is driven by enterprise buyers telling their providers: We need to control where our data lives and how it is processed.

The response has been significant. Microsoft launched Foundry Local, which lets organizations run large AI models on their own hardware in fully disconnected environments, and committed to processing Copilot interactions in-country for 15 nations by the end of 2026. Google and Oracle are pushing a model where AI services move to where the data lives rather than the other way around, deploying their cloud stacks inside customer infrastructure and sovereign regions.

These are not experimental initiatives. They are multi-billion-dollar structural shifts. And they tell me something important: The providers are not leading this conversation. They are responding to it.

But it is worth being honest about what sovereign offerings deliver today. They come with cost premiums, longer deployment timelines and in some cases a reduced feature set. The trade-off does not disappear. It changes shape. CIOs still need to understand what sovereignty means for their specific context, not just trust that a sovereign label on a cloud product solves the problem.

What CIOs should be doing now

If I were advising a CIO today, I would not start with tools or vendors. I would start with visibility.

Know exactly what data flows through which LLM and under what terms. Not at the contract level, at the actual usage level. Which teams are using which tools? Are they on consumer or enterprise tiers? Who approved the terms? If you cannot answer those questions today, that is the first problem to solve.

Map your data exposure against every jurisdiction you operate in, and do not stop at storage. Understand where inference happens. Understand where context is retrieved from. If you are operating across the EU, Saudi Arabia and Qatar, those are three different regulatory frameworks with three different enforcement postures, and the LLM layer touches all of them.

Audit for shadow AI. Not as a one-off exercise, but as a recurring part of your governance. Employees are not going to stop using AI tools. The goal is not to block adoption. It is to make sure adoption happens on terms the organization has chosen deliberately.

Do not default to local models out of fear or cloud models out of convenience. Make the trade-off intentionally, with real cost and capability analysis behind it. Understand what you gain and what you give up in each direction and make sure that decision is documented and owned at the right level.

Build procurement frameworks that treat LLM data handling as a first-class requirement. Not a footnote in a vendor assessment, but a core criterion alongside security, resilience and performance. If a provider cannot clearly explain what happens to your data, that is not a gap in their documentation. It is a gap in their offering.

The readiness gap is real. 95% of enterprise leaders say they plan to build sovereign AI foundations. Based on current research, only 13% are on track. The organizations that close that gap first will scale faster, win more trust and defend their choices with confidence. The rest will have the conversation forced on them.

From AI capability to AI sovereignty

For the last couple of years, the focus has been on what AI can do. Bigger models, faster outputs, more automation. That progress is real and I do not think anyone should slow down.

But I think the next phase will be defined by something different. Not capability, but control. Not what the model can do, but whether you can prove you know where your data went, who had access to it, what terms governed it and what happens to it next.

CIOs will not be judged on whether they adopted AI. They will be judged on whether they adopted it in a way they can defend. To a regulator. To a client. To a board. In plain language, with evidence they can stand behind.

In my first article for CIO Network, I argued that explainability is the control layer that makes AI safe to scale. Data sovereignty is the other half of that equation. Explainability answers “why did the system do that?” Sovereignty answers “where did the data go and who controls it?”

If you can answer both, you can scale with confidence. If you cannot, you are building on a foundation you do not fully own.

And once that foundation is questioned, it is very difficult to rebuild.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

In practice, that means setting the rules for identity, model access, permissions, logging and human approval before AI tools or agents are allowed to operate inside business workflows. The practical starting point is to identify where AI is already touching repositories, tickets, internal knowledge and business systems, then establish a minimum common control set across those entry points.

The first enterprise AI conversations I kept getting pulled into sounded like tooling debates.

Which copilot should we allow? Which model should we approve? How quickly can teams start using it in the IDE? How much faster will developers move?

Those are reasonable opening questions. In my experience, they are rarely the questions that determine whether AI scales safely inside an enterprise. They are just the entry point.

More than once, I have watched a meeting begin with a simple request to approve an AI coding assistant and end twenty minutes later in a debate about repository access, model approvals, prompt retention, audit trails and whether an agent should be allowed anywhere near a deployment workflow. That is the pattern that matters.

What I have seen instead is a predictable progression. First comes enthusiasm around copilots and coding assistants. Teams want faster code completion, quicker debugging, better documentation and help writing tests. Then the conversation shifts. Leaders start asking what these tools can see, where prompts go, which models are approved, whether responses are retained and how generated output should be reviewed. Then the issue gets bigger again. Once AI starts interacting with repositories, tickets, pipelines, internal knowledge, APIs and systems of record, the problem is no longer the assistant itself. It is the control plane around it.

That is why I no longer think this is mainly a coding tools story. Software development is simply where the governance problem becomes visible first. The broader enterprise issue is whether there is a shared layer for identity, permissions, approved model access, secure context, auditability and action boundaries before AI becomes an execution surface inside the business.

Software development is where the issue surfaces first

Development teams encounter this shift early because the platforms themselves are already moving beyond simple assistance. GitHub Copilot policy controls now let organizations govern feature and model availability, while GitHub’s enterprise AI controls provide a centralized place to manage and monitor policies and agents across the enterprise. GitHub has also made its enterprise AI controls and agent control plane generally available, explicitly positioning them as governance features for deeper control and stronger auditability. That is a sign that governance is starting to surface directly in product design.

Google is sending a similar signal. Gemini Code Assist is framed as support to build, deploy and operate applications across the full software development lifecycle, not just as an IDE helper. Its newer agent mode documentation describes access to built-in tools and Google’s data governance documentation says Standard and Enterprise prompts and responses are not used to train Gemini Code Assist models and are encrypted in transit. When vendors start documenting lifecycle coverage, tool access, data governance and validation expectations, the market is already telling you what matters next.

Microsoft is even more explicit. Microsoft Agent 365 is described as a control plane for AI agents, with unified observability through telemetry, dashboards and alerts. Microsoft’s Copilot architecture and data protection model put equal emphasis on permissions, data flow, Conditional Access, MFA, labeling and auditing. In other words, the control-plane idea is no longer theoretical. Major platforms are operationalizing it.

That is why the productivity-only debate misses the larger point. DORA’s 2025 report argues that AI primarily acts as an amplifier, magnifying an organization’s existing strengths and weaknesses and that the biggest gains come from the surrounding system, not from the tool by itself. The DORA AI Capabilities Model pushes the same idea further by laying out organizational capabilities required to get real value from AI-assisted software development. That lines up with what I have seen in practice. Enterprises do not fail because a model is impressive or unimpressive. They fail when they mistake local tool adoption for operating readiness.

The developer productivity research is mixed, which is exactly why leadership should be careful. MIT Sloan summarized field research showing productivity gains from AI coding assistants, especially among less-experienced developers. METR’s 2025 trial, by contrast, found that experienced open-source developers using early-2025 AI tools took longer in that setting. I do not read those findings as contradictions. I read them as a warning against building enterprise strategy around a narrow “hours saved in the IDE” lens. For leaders, the implication is simple: Mixed productivity data is a reason to strengthen governance and operating discipline, not to make strategy from benchmark claims alone.

The shift from assistant to execution layer

The real change happens when AI stops being a suggestion surface and starts becoming an execution surface.

That threshold arrives faster than many leaders expect. GitHub’s coding agent can create pull requests, make changes in response to comments and work in the background before requesting review. GitHub also documents centralized agent management and policy-compliant execution patterns using hooks to log prompts and control which tools Copilot CLI can run. Once a tool can act inside the delivery system, permission design stops being optional.

Anthropic’s documentation makes the same shift visible from another angle. Claude Code is described as an agentic coding tool that reads a codebase, edits files, runs commands and integrates with development tools. Anthropic’s sandboxing work explains how filesystem and network isolation were added to reduce permission prompts while improving safety. Its work on advanced tool use describes dynamic discovery and loading of tools on demand rather than preloading everything into context. Once tools can be discovered dynamically and invoked during work, governance must move above the assistant.

This is usually the point when the room changes. What started as a discussion about developer productivity becomes a discussion about identity, authority, logging, approval boundaries and who owns the risk if an AI-enabled action causes real enterprise impact. The issue is no longer, “Did the assistant help write code?” The issue becomes, “Who authorized this path from context to action?”

Serious governance starts above the tool

If an organization is serious about AI, governance must start above the assistant.

The first control is identity. Who is acting: A human, a service account, a bot or an agent? Microsoft’s Copilot architecture and agent management guidance make this concrete by tying access to user authorization, Conditional Access and MFA. That is the right instinct. AI does not remove the identity problem. It sharpens it.

The second control is permissions. What can the actor read, write, retrieve or execute? This is where many early deployments are still too loose. If an AI tool can read internal knowledge, query systems, write to a repository or trigger workflows, those capabilities need clear tiering just as privileged human access does. In practice, that usually means mapping agent permissions onto existing identity and access models so read, write, query and execution rights follow least-privilege rules rather than tool convenience. That can mean giving an agent read access to internal knowledge, limited write access in development environments and no production execution rights without an explicit approval boundary.

The third control is approved model access. GitHub now lets organizations govern model and feature availability in Copilot. Google documents edition-specific data handling and validation expectations. Enterprises need a way to decide which models are allowed for which workloads and data classes. Otherwise, every team ends up inventing its own routing logic and risk posture.

The fourth control is secure context. This is where real exposure often sits: Connectors, retrieval, embedded knowledge, prompts and tool calls. Anthropic’s work on context engineering for agents is useful because it shows how agents increasingly load data just in time through references and tools. That is powerful, but it also means context discipline matters as much as model discipline.

The fifth control is auditability. If a system suggests code, opens a ticket, retrieves enterprise content, triggers a tool or initiates a change, the enterprise needs evidence. GitHub’s enterprise agent monitoring and Microsoft’s auditing model both point in this direction. Governance without reconstructable evidence is not governance. It is optimism.

The standards are already telling us this

The control-plane framing matters because it aligns with where the standards bodies are already going.

NIST’s Secure Software Development Framework says secure practices need to be integrated into each SDLC implementation. NIST SP 800-218A extends that logic with AI-specific practices for model development throughout the software lifecycle. NIST’s Generative AI Profile treats generative AI as a risk-management problem spanning design, development, use and evaluation rather than as a narrow feature rollout. That is consistent with what enterprises are now learning in practice: Once AI touches real delivery and operating processes, governance becomes architectural.

The security community is saying the same thing. OWASP’s LLM Top 10 flags prompt injection, sensitive information disclosure, supply chain vulnerabilities and excessive agency as core risk areas. Those are not merely model-quality issues. They are control issues that show up when AI has context, tools and authority.

Software supply chain discipline matters here, too. SLSA ties stronger software trust to provenance and tamper resistance, while OpenSSF’s MLSecOps whitepaper and its Security-Focused Guide for AI Code Assistant Instructions show that AI-assisted development now needs explicit security practice in both pipelines and prompting. In an AI-assisted delivery environment, provenance and secure instruction design become more important, not less.

The market is moving toward a real control-plane layer

This is not just a framework conversation anymore. It is becoming a market category.

Forrester’s agent control plane research described enterprise needs across three functional planes: Building agents, embedding them into workflows and managing and governing them at scale. That matters because it validates the idea that governance has to sit outside the build plane if it is going to remain consistent as agents proliferate.

The market signal is clear. Microsoft is calling Agent 365 a control plane. GitHub has generally available enterprise AI controls and an agent control plane. Airia’s governance launch explicitly positions governance as a distinct layer alongside security and orchestration. The category is converging around the same problem statement: If agents can act, someone has to govern the conditions under which that action is allowed. Any control-plane solution worth serious consideration should work across models and tools while preserving policy consistency, auditability and clear operational boundaries.

The real leadership question

When this becomes real, I usually stop asking which assistant a team prefers and start asking different questions:

• Who is the actor, and under what identity does it run?
• What can it read, what can it write and what can it execute?
• Which models, endpoints and data flows are approved?
• What evidence survives an audit, an incident review or a board-level question?
• Where are the mandatory human checkpoints before an AI-assisted action becomes an enterprise action?

Those questions change the quality of the conversation quickly. They move the discussion out of demo mode and into operating model territory. That is also where alignment starts, because governance becomes a cross-functional operating issue for architecture, security, engineering and risk rather than a tooling preference inside one team.

In the conversations I have been in, that is usually the point when the room stops talking about tools and starts talking about control.

The wrong question for this phase is, “Which copilot should we standardize on?”

The better question is, “What control plane will govern AI wherever it runs?”

That is where serious enterprise AI governance starts.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Management for Germany’s record-holding football championship team aims to optimize processes and provide new digital services using AI. Here, CIO Michael Fichtner discusses what the club’s IT department has implemented, and what advantages they’ll bring to the company internally, and to fans around the world.

Why did FC Bayern migrate to SAP Cloud ERP Private?

Migrating to the cloud gives us access to innovation and other developments. Some SAP services are only available in the cloud environment, so these are now accessible to us. An important aspect was the simplified integration of other technologies or services predominantly or exclusively provided as cloud services.

Another important aspect was the realignment within IT. The migration allows us to focus more on process, application, and business innovation, and therefore on topics that’ll further develop and future-proof our company.

The use of highly available cloud infrastructures also provides us with additional security since in critical situations, we’ll benefit from professional backup and disaster recovery strategies. With all the dedication our employees have shown so far, this will be a further step toward professionalizing operations and further reducing risks.

In addition to security, scalability and flexibility are always important to us. Computing power, storage, and network resources can be scaled more quickly with a cloud provider. This is particularly significant in the frequent peak situations of our business model. For our projects, new systems like sandbox, test, and POC systems can be deployed faster and in a more standardized way, without requiring any investment or new equipment. Plus, security and compliance are becoming increasingly important for us. So migration allows us to leverage our partner’s established security features, and centrally managed access and authorization concepts simplify our operations. Certified data centers also directly support us to meet regulatory, association, and official requirements.

SAP’s strategy is consistently moving toward the cloud, and migration has allowed us to eliminate the risk of eventually having to rely on an outdated on-premise technology so we were able to eliminate legacy tech through migration as well as upgrade to modern, high-performance hardware.

How many applications or systems have been migrated to the cloud?

We migrated our multi-tiered SAP S/4HANA system. But before the migration, we worked together to consolidate our system landscape, merging 52 systems carrying fan data into S/4. There, the central fan database was established, the Golden Fan Record was built, and the data was combined into a redundancy-free, 360-degree view. So this approach was a significant milestone to implement our sovereign cloud strategy.

So we’ve only migrated one system physically, but in abstract terms, our phased approach allowed us to migrate data from all 52 systems to the cloud through consolidation, thus taking a big step toward controlled and consistent data sovereignty.

Which digital innovations does FC Bayern want to implement with the cloud?

Our business model is heavily influenced by peak situations like knockout phases in sporting competitions, live broadcasts, and special sales activities. In these situations, we need to not only scale technically, but provide innovative process solutions that reliably support peak loads.

Consider the short timeframes of ticket requests that must be processed during knockout stages. Or the launch of jerseys, where fans, even during peak periods, have the right to expect that goods will be delivered as quickly as possible. So in departments experiencing significant annual peaks in volume, it’s crucial employees receive highly automated support. Handling these seasonal peaks would otherwise be impossible.

We rely heavily on solutions supported by AI and digital agents, so developing them is always a joint initiative with our specialist departments.

What digital services and personalization strategies is FC Bayern planning to use to reach fans worldwide with the help of the new cloud platform?

Our aim is to address our fans in an individual, personalized way. The way forward is to move away from mass communication and large target groups or segments, and toward a personal approach, specifically tailored to the needs of each fan.

For this, we need the relevant data and ability to process large amounts of data in compliance with data protection regulations. This isn’t feasible without the appropriate infrastructure and scalability. We see personalized communication as a crucial element to remain relevant to our fans in the future. Mass mailings to fans via email, push notifications, or standardized content without specific relevance to the individual fan won’t help us remain attractive to them.

By providing targeted, relevant content, we want to further increase the attractiveness of FC Bayern Munich, and ensure the relationship with fans for the future.

What advantages do you expect from SAP Cloud ERP Private and AI?

A crucial factor in our decision to migrate was the conviction that we could significantly optimize our internal processes by using AI approaches. Specifically, we’re working on corresponding implementations in HR using SAP’s SuccessFactors and Concur. Initial approaches have also been developed and are being put in logistics and financial accounting. We expect this will allow us to increasingly automate more activities, freeing up colleagues in specialist departments to focus on specific tasks that require a particular approach or interaction. Ultimately, this will enable us to provide better service to fans as we gain time to address other issues.

What role did digital sovereignty or data sovereignty play in the decision to migrate to the SAP cloud?

Digital sovereignty, and control over our data and the data of our fans, have been of paramount importance for many years, and have guided our actions for just as long. Driven by this principle, we’ve developed and operated our key applications ourselves.

With the capabilities our partners have made available to us, we could implement these requirements in a sovereign cloud environment without compromising standards. So we’re confident we’ve not created any dependencies and will remain operational in the years to come. We’re convinced that the de facto and legal control of our critical data is sustainably ensured in our chosen setup.

The data sprawl problem is worse than anyone admits

Before a DSPM tool can protect data, it must find it. That sounds straightforward. In practice, it is the first place most programs quietly begin to unravel.

Enterprises have been operating in hybrid and multi-cloud environments for a long time. Data has followed every workflow — into Salesforce, into SharePoint, into dozens of S3 buckets that were created by developers who have since moved on, and into collaboration tools adopted during the pandemic without any formal data classification policy attached. Nobody tracked it systematically. Research from Cyera’s 2024 DSPM Adoption Report found that 90% of the world’s data was created in just the last two years, and total data volume by 2025 reached 181 zettabytes. Security teams are being asked to govern a landscape that is growing faster than any tool or team was designed to handle.

When DSPM scanners go to work on a large enterprise environment, the volume of findings almost always exceeds initial expectations — sometimes by an order of magnitude. One organization I worked with discovered sensitive customer PII in seventeen cloud storage locations that they had no formal record of. Another found regulated financial data sitting in a collaboration workspace that had been shared with an external contractor two years prior and never revoked.

The visibility is genuinely valuable. But, as Wiz notes in their DSPM framework, visibility without remediation capacity is just a longer list of things that can go wrong. And that is exactly where the first real friction begins.

Ownership is a political problem, not a technical one

DSPM tools are exceptionally good at identifying data risk. They are not designed to resolve the organizational question of who is responsible for fixing it. That question, in most enterprises, does not have a clean answer.

Security teams surface the finding. The data sits in a business unit’s environment. The IT team may own the cloud account, but the data owner is in Finance, HR, or a product team operating on a separate roadmap and budget cycle. When the DSPM platform generates a remediation ticket, the question of who closes it — and who gets measured on closing it — is rarely answered in advance.

This creates what I call the remediation gap. Findings accumulate. Risk scores rise. But nothing gets fixed, because no single team has both the authority and the incentive to fix it. Security points at the business. The business points at IT. IT points at the data owner. The data owner has a product launch in six weeks and no security budget. Forcepoint’s DSPM implementation research confirms this pattern: Even capable platforms underdeliver when rollout turns into a scanning project with unclear ownership and remediation that lives in a permanently deferred backlog.

I have watched this dynamic play out in organizations across industries. It is not a technology failure. It is a governance failure — and no DSPM platform in the market today ships with a solution to it. That solution must be built by leadership, before deployment, with teeth. That means defined data ownership models, escalation paths and accountability metrics that connect to performance conversations, not just security dashboards.

Classification debt is real, and it goes well with compounding

Every DSPM implementation depends on one foundational input: A coherent data classification framework. Most enterprises do not have one that is current, enforced, or agreed upon across business units.

Organizations are equipped with policy documents written five years ago, and what was defined there, nobody uses consistently. What adds more is a growing volume of unstructured content that was never classified at all. According to a 2024 industry survey cited by Securiti, 83% of IT and cybersecurity leaders assert that lack of visibility into data contributes significantly to their weak security posture — a figure that points directly at the classification gap sitting underneath most programs.

DSPM tools apply machine learning to infer sensitivity from data patterns — and they are increasingly good at it. But inference is not a substitute for intentional classification. False positives create noise. False negatives create blind spots. Both erode trust in the platform over time. And once analysts stop trusting the findings, the program stalls regardless of how sophisticated the tooling is.

The harder truth is that many organizations use the DSPM project as a forcing function to finally build the classification framework they should have built years ago. That is not inherently wrong. But it dramatically expands the scope and timeline, and it requires business stakeholder engagement that security teams are rarely resourced to drive on their own. Executives who budget for a DSPM tool without budgeting for the classification work alongside it are setting their programs up for a slow, expensive drift toward shelfware.

Integration complexity is systematically underestimated

DSPM vendors will show you a connector library that spans AWS, Azure, GCP, Microsoft 365, Salesforce, Snowflake and a long list of other platforms. What the demo does not show you is what happens when your specific version of a legacy ERP system does not match the connector’s assumptions or when your on-premises database sits behind a network segment the cloud-native scanner cannot reach without significant architectural change.

Enterprise environments are heterogeneous by nature. Palo Alto Networks’ market analysis puts the DSPM market on a trajectory toward $2 billion by 2025, growing at rates between 25% and 37% annually — a reflection of just how aggressively organizations are investing in this space. But investment velocity and implementation maturity are not the same thing. The average large organization runs hundreds of distinct data stores across multiple cloud providers, legacy systems and third-party SaaS applications. Getting DSPM coverage across all of them is not a deployment — it is an ongoing engineering program.

Connectors break when APIs change. New data sources appear with every acquisition and product build. Maintaining coverage requires dedicated resources that are rarely factored into the initial business case. Executives should push their vendors on exactly which environments will have full coverage at go-live versus which ones are on a roadmap with no committed timeline. The distinction matters enormously because a DSPM deployment with significant coverage gaps gives a false sense of security that can be more dangerous than no deployment at all.

This is a point worth reinforcing with your procurement team: Gartner’s Market Guide for DSPM explicitly flags that organizations can no longer separate data visibility from data control — and that coverage depth, not just breadth, is the critical variable when evaluating platforms.

Alert fatigue arrives faster than expected

A fully operational DSPM deployment in a large enterprise will generate findings at a volume that most security operations teams are not built to absorb. The irony is that the better the tool works, the faster alert fatigue sets in.

Risk prioritization is the answer in theory. In practice, prioritization logic requires ongoing tuning that takes months of calibration with your specific data environment. Varonis, in their DSPM guidance for CISOs, makes the point directly: The goal should not be to generate a list of findings but to surface meaningful, actionable alerts that can be remediated — ideally with automation doing the heavy lifting. Most implementations fall well short of that standard in the early months.

In the meantime, analysts are triaging hundreds of findings per week, many of which turn out to be acceptable risks or known exceptions. Teams burn out. Findings get acknowledged and deprioritized. The board dashboard shows a healthy posture score that no longer reflects ground reality. Zscaler’s analysis of cloud data security challenges identifies this precisely: Security teams need AI and ML-powered prioritization not just to reduce noise but to help analysts focus effort on the data exposures that could realistically lead to a breach.

This is not an argument for turning off the tool. It is an argument for honest capacity planning. If your security operations team is already stretched, a DSPM deployment without additional analyst headcount or a meaningful automation investment is not going to improve your security posture. It is going to add a new category of noise to an already overloaded function.

What good looks like

None of the friction described here is insurmountable. Organizations that get DSPM right tend to share a few common attributes that have nothing to do with which vendor they chose.

They treat DSPM as an organizational change program, not a technology deployment. They invest in governance structures before they deploy scanners. They define data ownership at the business unit level with clear accountability, and they build that accountability into how people are measured and managed. They budget for the classification work alongside the tooling. They phase their integration roadmap honestly, scope the first phase to environments where coverage will be complete, and build confidence before expanding.

They also pay attention to what Microsoft’s research on enterprise data security posture flags as the underlying imperative: Organizations must stop seeing data security as a collection of individual tools and start treating it as a holistic program anchored in measurable business outcomes. That shift in framing changes everything — from how the board conversation is structured to how remediation accountability is assigned across the business.

Most importantly, they have executive sponsorship that goes beyond signing the purchase order. The CISOs who successfully land DSPM programs are the ones who have a CFO, COO, or CEO who understands that data security risk is a business risk — and who is willing to hold business unit leaders accountable for their piece of it.

DSPM, at its best, gives your enterprise the situational awareness it needs to make informed decisions about data risk. The organizations that leverage awareness as a genuine security improvement are the ones that walk in with eyes open — prepared for the friction, staffed for the remediation work and governed for the accountability.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Most enterprise AI investments today focus on models, compute and tooling. The assumption is that intelligence is the binding constraint and that a more capable model will produce better outcomes across every dimension that matters. This is a reasonable starting point, but it is also where most initiatives go wrong.

The models organizations are deploying were trained on public data at scale. None of your internal systems, customer schema, pricing logic or support taxonomy appeared in that training.

When a model encounters your internal data, it processes it as best it can, but without the grounding that comes from having been trained on it. Early AI initiatives are struggling not because the models are weak, but because the context they need to operate reliably inside your organization is something they have never seen before.

Data engineering holds the key to this context.

Why context breaks first

Think about what an AI agent handling a support escalation needs to function well: The customer’s support history across time, not just the most recent ticket. Billing records matter too, because the character of a problem often depends on what the customer is paying for and whether anything has changed recently. Product usage data is equally essential, as what a customer reports is frequently explained by how they have been using the product. None of these things live in a single place, as they are scattered across systems that were each built by different teams, on different timelines, with different definitions of what a customer record is supposed to capture.

Human agents work around these gaps through judgment developed over time. They know which system to trust for a particular type of question, they know the usage data runs six hours behind and they know how to weigh conflicting signals based on context that is never written down anywhere. AI systems do not have that judgment. They process whatever they receive and act on it, which means that when the context is inconsistent or incomplete, the output reflects that, not as a visible error but as a subtly wrong decision. The customer notices before anyone on your team does.

When bad data stops being annoying and starts being operational

In the analytics era, data quality problems surfaced as numbers that looked off in dashboards. Analysts were the error-detection layer, and when something looked wrong, they would investigate, find the issue and get it fixed. The feedback loop was slow, but it existed, and it caught most problems before they reached the business in any consequential way.

AI agents making operational decisions do not have that buffer. They have no way of knowing that a schema migration introduced silent gaps or that a pipeline is running four hours late. Refunds go out incorrectly because the billing context was incomplete at the moment of decision.

What an analytics team could absorb as an occasional anomaly in a report becomes a real problem when an automated system acts on degraded context hundreds of times a day before anyone identifies the pattern. The volume is what makes it dangerous, and by the time it surfaces, the damage is already distributed across thousands of interactions.

The role data engineers play now

For the past decade, data engineering meant building pipelines that fed warehouses so analysts could query data and produce dashboards. The work was foundational but treated as background infrastructure, and its value was measured in pipeline reliability, query performance and reporting freshness.

The agent era changes the purpose of that work entirely. When AI systems make operational decisions, the goal is no longer producing data that is queryable. The goal is producing context that is reliable enough for a system to act on, and those are different problems with different requirements. That starts with entity resolution across systems, providing a consistent and trustworthy answer across every data source that touches them.

This also means handling late-arriving data explicitly, because agents cannot act on a state of the world that no longer holds. Freshness thresholds need to be calibrated to the decision type, since a personalization recommendation can tolerate six-hour-old usage data in ways that a refund workflow cannot. Lineage needs to survive schema changes and reorganizations, so that the provenance of any piece of context can be traced when something goes wrong.

None of that is a model problem, nor does it yield to prompt engineering. This is data engineering work, and organizations that treat it as anything else will spend a long time debugging production failures that look like AI problems but are infrastructure problems.

Context is only half the problem

Getting the right information to an agent is necessary, but it is not sufficient. There is a second challenge that most organizations have not yet confronted: How do you coordinate, govern and operate dozens or hundreds of autonomous agents making real decisions across your business?

Agent frameworks handle reasoning well. What they do not handle is everything around the agent: Scheduling when it runs, controlling what it is allowed to spend, enforcing who can approve its decisions, managing retries when external systems fail and ensuring that when an agent needs human sign-off, it does not tie up compute for hours while it waits. These are not AI problems. They are operational infrastructure problems, and they are the same class of problems that orchestration platforms have been solving for data pipelines for over a decade.

One agent answering questions in a sandbox is a proof of concept. Fifty agents making operational decisions across finance, compliance and customer operations is a fleet management problem, and it requires the same kind of scheduling, governance, cost controls and auditability that enterprises already demand from their data infrastructure.

Orchestration is typically the one layer that already has visibility across platforms, spanning your warehouse, your transformation layer, your external APIs and your operational databases. That cross-platform vantage point is what makes it possible to build a context layer that is comprehensive rather than siloed.

Governance needs to execute at runtime, not live in documentation. Policies about data access, cost limits and human approval requirements need to be enforced in code as agents run, not described in guidelines that agents cannot read and humans forget to follow.

What this means going forward

The organizations that deploy AI agents at scale will have invested in two things before those agents reach production.

First, a context layer that gives agents a reliable, cross-platform understanding of the enterprise’s data. This means not just raw access to tables, but semantic knowledge of what the data means, where it comes from and how much to trust it.

Second, an operational layer that governs how agents act, with the scheduling, cost controls, auditability and human-in-the-loop checkpoints that enterprise deployment demands.

These two investments are not independent. They form a flywheel. Better context makes agents more effective, which drives broader adoption, which generates richer operational metadata, which deepens the context layer further.

Data engineers are becoming the people who determine whether automated decisions are trustworthy, not because they control the models but because they control both the context on which those models operate and the infrastructure through which they act. The organizations that understand this early will keep building on it. The ones that keep treating data engineering and orchestration as background infrastructure will keep rediscovering the same production failures, just with different names on the postmortem each time.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

“Data is the new oil” is one of the most overused phrases in enterprise technology. Yet it still captures something fundamentally true about the modern enterprise, if we extend the analogy.

Crude oil has limited value until it is refined into the fuels, chemicals, plastics, polymers, synthetic fibers, and industrial materials that power entire societies and permeate nearly every aspect of modern life. Similarly, the real value of data does not lie in its raw accumulation but in its transformation, through systems, into decisions, intelligence, and operational impact.

In this context, converged analytics has emerged as the refinery of the data economy. Organizations that lead will be those with the most effective refining layer. 

Traditional analytics architectures evolved in silos, no longer compatible with the dynamic AI world

Over the past decade, enterprises have invested heavily in extracting, storing, and moving data. Data lakes, warehouses, streaming platforms, and cloud pipelines have created an unprecedented accumulation of information. And yet only 13% of enterprises globally are successfully achieving ROI from their AI initiatives. 

“Enterprises now sit on massive reserves of structured, semi-structured, and unstructured data generated by applications, devices, and digital interactions. Yet despite this abundance, many CIOs still struggle to translate data into consistent, real-time business value. The issue is not scarcity—it is fragmentation,” says Quais Taraki, CTO, EnterpriseDB (EDB). 

The value of data is trapped when it’s siloed and spread across systems and teams. 

Transactional systems were optimized for operational workloads. Analytical systems were built for reporting and historical analysis. Streaming systems handled real-time events. Each requires different infrastructure, tools, and governance models. Data has to be copied, moved, transformed, and reconciled across environments before it can be used. This introduces latency, complexity, duplication, and risk. Insights often arrive too late to influence outcomes, while operational systems remain disconnected from analytical intelligence.

Converged analytics solves the largest challenge for AI-ready data

What makes crude oil valuable is not extraction alone but its combination with the refinery—the integrated industrial system that processes, synthesizes, and upgrades raw hydrocarbons into usable products. 

Comparable in the world of enterprise technology is converged analytics, which addresses data systems fragmentation by unifying capabilities into a single, sovereign architectural paradigm. It brings together transactional processing, analytical processing, and streaming-data handling within a cohesive system. 

“Instead of moving data across multiple specialized platforms, converged analytics enables computation to occur where the data resides, across different workloads and time horizons. This integration collapses latency, reduces duplication, and preserves context, allowing organizations to move from retrospective analysis to real-time decision-making,” says Taraki of EDB.

AI raises the stakes 

While generative AI and now agentic AI have captured executive attention, their effectiveness depends on access to fresh, well-governed, and contextually rich data. Models trained on stale or fragmented datasets deliver limited value. 

Converged analytics provides the foundation for continuous data pipelines, real-time feature engineering, and low-latency inference. It enables architectures such as retrieval-augmented generation and supports ongoing feedback loops that improve model performance over time. In this sense, it is not just complementary to AI; it is a prerequisite for operationalizing it at scale.

AI also intensifies the cost of fragmentation. 

“Every time data must be copied, moved, or reconciled across specialized systems, organizations introduce latency, duplication, and loss of context,” says Taraki. 

Converged analytics reduces that friction by enabling computation closer to where data already resides, allowing decisions to happen in real time rather than after the fact.

Converged analytics offers non-AI and data companies a pathway to increased relevance and value

Unlike point solutions that address isolated parts of the data pipeline, converged analytics platforms sit at the center of the entire data lifecycle. They intersect with storage, compute, networking, and security, making them a natural integration point for a wide range of technologies. 

For hardware vendors, this creates demand for high-performance infrastructure capable of handling mixed workloads with low latency and high throughput. For service providers, it opens the door to long-term engagements around platform design, deployment, optimization, and governance.

Converged analytics workloads are not peripheral use cases; they are core to business performance. Real-time fraud detection, predictive maintenance, personalized customer experiences, and supply chain optimization all depend on the ability to process and act on data as it is generated. These workloads are both compute intensive and mission critical, making converged analytics an especially valuable category for vendors seeking to align with enterprise priorities.

The shift toward hybrid and edge computing environments adds another dimension to the opportunity. As enterprises distribute workloads across cloud, on-premises, and edge locations, the need for consistent analytics capabilities across these environments becomes critical. 

Converged analytics platforms are increasingly designed to operate seamlessly across this spectrum, enabling data to be processed and acted upon wherever it is generated. This creates additional insertion points for both hardware and services vendors, from edge devices and accelerators to orchestration, lifecycle management, and ongoing operational support.

Making it work at enterprise scale

In the early stages of the oil industry, value was concentrated in extraction. Over time, it shifted to refining and distribution, with efficiency, scale, and integration determining competitive advantage. The same transition is now underway in the data economy. Enterprises already possess vast reserves of data; the differentiator will be their ability to refine it rapidly, efficiently, and in context.

Converged analytics represents that refining capability. It is why hardware vendors are optimizing for data-intensive workloads and why services firms are reorganizing around platform engineering. But the practical reality is that this refining layer cannot succeed as software alone. It depends on the hardware, services, support, and operational expertise required to deploy and run it at scale.

For CIOs, this is no longer just a question of architecture. It is a prerequisite for making data a true driver of business value. To learn more, visit us here.

I recently sat down with a group of enterprise technology leaders to discuss artificial intelligence deployments. It was a spirited discussion with lots of learnings. The consensus among the group highlighted a rapid transition away from simple chat applications. Companies want autonomous agents capable of executing multi-step workflows across human resources and customer service departments. I listened to chief information officers describe the harsh reality of moving agentic workflows from pilot programs into live production. Scaling the technology exposes severe infrastructure gaps. Dropping high-speed agents into old systems creates immediate operational chaos. Achieving business value requires building an architecture of flow.

Building an architecture of flow replaces isolated bottlenecks with continuous execution. Continuous execution ensures intelligence moves instantly across the organization. The universal context layer serves as the technological connective tissue enabling continuous execution. The layer sits beneath the applications. Bridging disparate legacy systems provides a common language for both autonomous agents and human workers.

The data fragmentation crisis

Decades of disjointed data management now block progress. During my conversations with the technology executives, data fragmentation emerged as the primary roadblock. Artificial intelligence agents require absolute ground truth to function securely. Fragmented legacy systems trap enterprise intelligence in isolated silos. Organizations must build the universal context layer to orchestrate underlying data before turning autonomous agents loose on complex workflows. I see companies investing millions in large language models while completely ignoring data readiness.

The 2025 Gartner Hype Cycle for Artificial Intelligence reveals a stark reality regarding infrastructure. Analysts report 57 percent of organizations remain unprepared to support artificial intelligence due to inadequate data foundations. Deploying autonomous agents demands clean information. Relying on disconnected databases forces new autonomous systems to hallucinate at unprecedented speeds. Chief information officers must connect raw data directly to daily workflows. Providing a secure framework prevents compliance disasters and protects customer data. Establishing a solid foundation guarantees agents access to accurate historical records. Integrating scattered documents into a unified stream gives the autonomous agent the exact context needed to complete a task successfully.

Identity and the naked agent

Identity and access emerge as distinct operational hurdles. The leaders I spoke with expressed deep concern over exposing excessive data scope to autonomous agents working on their behalf. Deploying naked agents without rigid operational boundaries guarantees compliance disasters. An autonomous agent scanning a corporate network will inevitably find unsecured payroll files or confidential merger documents unless teams establish strict access limits.

The architecture of flow establishes strict connective tissue. Strict connective tissue ensures agents only receive the exact context required for the specific task. Relying on perimeter defense fails in an agentic world. We must adopt an identity-first zero-trust security posture to govern machine behavior. Providing the exact context at the exact moment limits the blast radius of a potential breach. Governance becomes an enabler of speed rather than a blocker. Security protocols must evolve to match the speed of algorithmic execution. Establishing proper guardrails allows innovation to flourish safely. Giving an agent partitioned access protects the enterprise from internal data leaks. The universal context layer authenticates every request dynamically based on the active workflow.

Budgeting for algorithmic operations

The financial reality of autonomous agents forces a complete restructuring of technology budgets. Multiple executives at our dinner table discussion asked how to budget for processing tokens across different departments. Processing tokens operates like a utility cost. Paying for generative AI resembles paying an electric bill. Companies want to deploy agents to speed up customer onboarding workflows and back-office operations. Expanding the agentic footprint increases token consumption exponentially.

Treating token consumption as a standard software licensing fee breaks financial models. I recommend finance teams redefine AI spending as operating expenses. The ongoing cost of computing requires constant monitoring and optimization. The architecture of flow provides visibility into system usage. Leaders can track exactly which departments consume the most resources. Transparency allows organizations to allocate funds dynamically based on operational outputs. Aligning computational spending directly with business outcomes creates a sustainable growth model.

The shift toward focused language models

Enterprise technology leaders recognize the inefficiency of using massive foundation models for every request. Routing simple database queries through giant language models wastes processing power and money. Chief information officers now pivot toward deploying smaller language models. Smaller language models trained on specific enterprise data execute narrow workflows more efficiently. Operating a focused model reduces computing costs drastically. A specialized model designed purely for reviewing human resources policies requires a fraction of the token budget.

Building an architecture of flow accommodates a multi-model ecosystem. The universal context layer routes the specific task to the most efficient model available. Connecting a massive foundation model to a series of smaller agentic tools creates a highly optimized digital workforce.

Navigating the interoperability mandate

From my early days at Gartner, covering messaging, communication and collaboration, intra- and interenterprise collaborative workflows have always been hampered by the thorny issue of interoperability. The multi-vendor reality in the enterprise remains undeniable. No single platform will dominate the enterprise artificial intelligence stack. Organizations currently deploy multiple systems across various departments to solve specific problems. Marketing teams use one large language model while software engineering teams use a completely different coding assistant. Interoperability demands an underlying architecture giving disparate agents and legacy databases a common language to flow together seamlessly.

Vendors historically push locked ecosystems to trap customer data. The future digital workplace requires open communication protocols. I continually advocate for frameworks allowing different models to communicate effortlessly. Industry standards like the Model Context Protocol demonstrate the growing demand for universal connectivity. The universal context layer acts as the universal translator. Translating raw processing power into immediate business context breaks down vendor lock-in. Agent-to-agent collaboration requires a shared technological foundation.

Elevating the resolution specialist

Buying isolated software applications perpetuates the static enterprise. Organizations must stop hoarding disconnected tools to fix fragmented workflows. My discussions with industry peers confirm a shift in perspective. The boardroom conversation moves past pure cost reduction. Enterprises deploy agentic workflows to accelerate high-return operations and client-facing experiences. Equipping the human workforce with agentic speed transforms standard employees into empowered resolution specialists.

Removing internal system friction directly orchestrates flawless external customer outcomes. A resolution specialist equipped with instant context executes better customer outcomes regardless of the market sector. The human worker spends zero time searching for information across disconnected applications. Technology leaders must start orchestrating the flow of context. Designing systems around secure boundaries and interoperability guarantees a more sustainable technological advantage.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Como todo director de sistemas de información sabe, el éxito de la IA depende de unas prácticas de datos sólidas como una roca. Pero, dado que los directores generales y los consejos de administración han puesto el énfasis en las transformaciones digitales en los últimos años, la financiación destinada a los esfuerzos de transformación de la gestión de datos ha sido, en el mejor de los casos, parcial. Ahora, con la IA en lo más alto de la agenda de los directores generales, muchos CIO se encuentran en un aprieto, al tener que reformar también las operaciones de datos y hacer frente a años, o décadas, de deuda de datos acumulada.

Si una empresa tiene deuda de datos, la IA la pondrá en evidencia. De hecho, la deuda de datos puede provocar tasas de fracaso devastadoras en los proyectos de IA. Para los líderes tecnológicos, no hay mejor momento que el presente para saldar esta deuda con una estrategia de corrección integral.

La deuda de datos puede surgir por diversas razones, entre ellas prácticas de gestión de datos antiguas y obsoletas, atajos y concesiones en la infraestructura para cumplir objetivos a corto plazo, fuentes de datos mal documentadas y prácticas ineficientes de almacenamiento de datos.

La firma de análisis IDC, en su Informe de previsiones para la agenda de los CIO en 2026, señala que, para 2027, los CIO que retrasen la puesta en marcha de la corrección de la deuda de datos se enfrentarán a tasas de fracaso de la IA un 50% más altas y a un aumento de los costes, ya que el bajo rendimiento de los modelos pone de manifiesto problemas derivados de datos aislados, redundantes o de mala calidad. “Estos hallazgos refuerzan la idea de que escalar la IA requiere una inversión disciplinada en bases de datos y plataformas integradas, y que posponer estos fundamentos corre el riesgo de convertir la ambición de la IA en una fricción operativa sostenida”, reza el informe.

“La IA no crea problemas de datos; los pone de manifiesto y los acelera”, afirma Hrishikesh Pippadipally, CIO de la firma de contabilidad y asesoría Wiss. “Cuando las organizaciones carecen de procesos estandarizados, definiciones coherentes y una gobernanza de datos disciplinada, los datos se deterioran naturalmente con el tiempo. Ese deterioro puede no ser visible en entornos de generación de informes tradicionales, pero los sistemas de IA sacan a la luz esas inconsistencias rápidamente”.

La deuda de datos es a menudo el resultado de la deriva de los procesos: múltiples equipos que utilizan definiciones diferentes, estándares de introducción de datos inconsistentes y sistemas aislados que evolucionan de forma independiente, afirma Pippadipally. “Sin estandarización y una propiedad clara, incluso los sistemas modernos se degradan”, afirma. “En nuestra organización, hemos aprendido que la corrección no consiste solo en limpiar los datos históricos. Se trata de instaurar procesos disciplinados que eviten el deterioro en el futuro: una propiedad clara de los datos, flujos de trabajo estandarizados y una gobernanza integrada en las operaciones diarias”.

Dicho esto, no todas las iniciativas de IA se ven bloqueadas por datos imperfectos, afirma Pippadipally. “Hay casos de uso más pequeños y bien delimitados, como el resumen de documentos, la asistencia en la redacción, la señalización de anomalías o el apoyo a la conciliación, que pueden aportar valor con la verificación por parte de personas”, afirma. “Estas aplicaciones contenidas permiten a las organizaciones desarrollar la madurez de la IA mientras se llevan a cabo mejoras fundamentales en los datos”.

Un problema creciente que requiere una solución rápida

La deuda de datos, un problema generalizado en la mayoría de las organizaciones, ha crecido de forma orgánica a lo largo de décadas. Además del creciente énfasis en la recopilación de datos, las empresas también han acumulado deuda de datos a lo largo de años de fusiones y adquisiciones, así como por la implementación de nuevos sistemas y servicios, ya sea a nivel de toda la empresa o por departamentos.

“Los sistemas se han ido superponiendo en respuesta a necesidades inmediatas, adquisiciones, requisitos normativos o preferencias departamentales”, afirma Pippadipally. “Con el tiempo, los procesos y estándares inconsistentes dan lugar a entornos de datos en silos”.

Además, las ineficiencias en la gestión de datos se han abordado históricamente con soluciones manuales, dice Pippadipally. “Los equipos conciliaban los informes de forma manual”, explica. “Los analistas compensaban las definiciones inconsistentes. Pero la IA reduce la tolerancia a la ambigüedad. Cuando los sistemas automatizados operan a gran escala, las inconsistencias se multiplican en lugar de compensarse”.

Si una empresa tiene deuda de datos, la IA la pondrá en evidencia

Es vital abordar esto ahora porque las iniciativas de IA avanzan más rápido que la madurez de los procesos. Hay un claro sentido de urgencia. “Si las organizaciones no institucionalizan la disciplina y la estandarización de los procesos, corren el riesgo de automatizar el caos en lugar de mejorar los resultados”, afirma Pippadipally. “El problema no es simplemente la mala calidad de los datos; es la ausencia de una gobernanza sostenida que mantenga la fiabilidad de los datos a lo largo del tiempo”.

Para muchas empresas, la deuda de datos puede permanecer oculta mientras llevan a cabo actividades tradicionales de inteligencia empresarial o análisis puntuales, afirma Juan Nassif, director técnico regional del proveedor de desarrollo de software BairesDev. “La IA es diferente; es mucho menos indulgente y expone rápidamente duplicados, definiciones incoherentes, contexto faltante y “campos misteriosos” con un linaje poco claro”, afirma Nassif. “Cuando se pasa de la fase piloto a una escala mayor, esos problemas se manifiestan en forma de bajo rendimiento de los modelos, ciclos de iteración más largos y aumento de los costes operativos. Para nosotros también es una preocupación absoluta, y lo consideramos un requisito previo para escalar la IA de forma responsable”.

Si los datos están incompletos, son incoherentes o están duplicados, los resultados de los modelos de IA dejan de ser fiables. “Eso puede traducirse en respuestas erróneas, recomendaciones deficientes o automatizaciones que fallan en el peor momento”, afirma Nassif. “Los equipos acaban dedicando la mayor parte de su tiempo a lidiar con los datos, reelaborar los flujos de trabajo y compensar las entradas deficientes con ajustes repetidos y excepciones”.

Existe algún tipo de deuda de datos en todos los sectores y en organizaciones de prácticamente todos los tamaños. “Soy testigo de las consecuencias de la deuda de datos en mi trabajo diario con colegios del Reino Unido cada semana”, afirma Mark Friend, director de Classroom365, que asesora a instituciones educativas sobre tecnología, arquitectura y estrategias.

“La mayoría de la gente da por sentado que, al adquirir la última herramienta de IA, todos sus problemas quedarán resueltos, por muy desordenada que esté la base subyacente”, afirma Friend. “Mi experiencia al respecto es que incluso el software más caro resulta inútil si los datos de entrada no son fiables». La deuda de datos es «un riesgo fundamental para la estabilidad institucional”, agrega.

Consejos para una corrección eficaz de la deuda de datos

La corrección de la deuda de datos a nivel de toda la empresa puede ser una tarea significativa y costosa que afecta a múltiples aspectos del negocio. No se trata solo de una cuestión tecnológica, sino también de disciplina. Requiere limpiar los datos históricos, así como reforzar la gobernanza de los procesos para evitar repetir los errores o las malas prácticas del pasado.

Por ello, desarrollar y ejecutar una estrategia eficaz requiere un enfoque organizado y minucioso. A continuación, se ofrecen algunos consejos de los expertos.

Conseguir el apoyo de la alta dirección y del consejo de administración

Cualquier iniciativa de TI importante suele necesitar la aceptación de los altos ejecutivos de la empresa e incluso de los consejos de administración, especialmente si se trata de una gran empresa global. La corrección de la deuda de datos no es diferente. Existe un riesgo financiero significativo si la corrección no cuenta con la aprobación y el respaldo total de los altos ejecutivos y los miembros del consejo de administración.

Explicar las posibles ramificaciones es una buena forma de llamar la atención sobre la necesidad de la corrección. “Haga visible la deuda de datos y vincúlela al riesgo empresarial”, afirma Nassif. “La deuda de datos no se considerará prioritaria hasta que se relacione con las tasas de fallo de la IA, el aumento de los costes y el riesgo de incumplimiento normativo”.

La deuda de datos es ahora un riesgo a nivel de consejo de administración, reflexiona Adrian Lawrence, fundador de la empresa de selección de ejecutivos NED Capital, que asesora a consejos de administración y responsables financieros sobre gobernanza de datos empresariales, integridad de los informes y preparación para la IA. “Veo cómo aumenta la presión a medida que los consejos de administración vinculan su inversión en IA a los objetivos de productividad y rentabilidad, pero los datos inconexos de finanzas, ventas y operaciones socavan gravemente la precisión de los modelos”, relata. “Ponen al descubierto las deficiencias que las actualizaciones [de la plataforma empresarial] y la tecnología obsoleta no han abordado por completo”.

El éxito en la corrección de la deuda “exige el respaldo de la dirección, una gobernanza de datos disciplinada y una limpieza de la arquitectura por fases que trate los datos como un activo en el balance”, afirma Lawrence.

Estandarizar los procesos básicos antes de ampliar la IA

Para que los beneficios de la corrección de la deuda de datos sean más duraderos, las empresas deben estandarizar sus procesos empresariales básicos.

“La calidad de los datos refleja la calidad de los procesos”, afirma Pippadipally. “Los líderes deben ponerse de acuerdo sobre flujos de trabajo, definiciones y uso del sistema estandarizados antes de esperar que la IA funcione de manera coherente. Sin la estandarización de los procesos, los esfuerzos de corrección serán temporales”.

La IA funciona mejor en entornos predecibles, recalca Pippadipally, y la estandarización crea la estabilidad que la IA requiere.

BairesDev ha integrado comprobaciones automatizadas de la actualidad, integridad, duplicados y cambios de esquema de los datos, de modo que los problemas de calidad de los datos se detectan antes de que lleguen a los flujos de trabajo de análisis o IA, afirma Nassif.

Establecer la propiedad de los datos y una gobernanza continua

Otra forma de garantizar los beneficios a largo plazo de una iniciativa de corrección es contar con procesos de gobernanza y rendición de cuentas continuos. “La corrección de datos no es una iniciativa de limpieza puntual”, afirma Pippadipally. “Asignar una propiedad clara a nivel de dominio y establecer una supervisión continua evita que los datos se degraden de nuevo”.

Esto es importante, porque la gobernanza garantiza la sostenibilidad. “Sin disciplina, las organizaciones vuelven a acumular deuda de datos incluso después de los esfuerzos de limpieza”, agrega Pippadipally.

“Hemos reforzado la propiedad de los conjuntos de datos y estandarizado las definiciones empresariales comunes, para que los equipos no tengan que formarse ni recurrir a ‘versiones de la verdad’ contradictorias”, afirma Nassif. “Hemos reforzado nuestras prácticas de catalogación y linaje, para que los equipos puedan rastrear de dónde proceden los datos, cómo se transforman y quién puede utilizarlos —algo fundamental tanto para la confianza como para la gobernanza—“.

El mayor cambio es de mentalidad. “No tratamos la corrección de datos como una limpieza puntual”, dice Nassif. “La tratamos como una ingeniería continua con medidas de seguridad que evitan que la deuda vuelva a acumularse”.

Priorizar casos de uso de IA de alto valor y delimitados

Mientras las grandes iniciativas de modernización de datos avanzan dentro de una organización, los CIO pueden implementar la IA en áreas de alcance limitado donde los resultados sean verificables y la supervisión humana sea sencilla, cuenta Pippadipally. “Algunos ejemplos son el apoyo a la redacción, las conciliaciones controladas, la clasificación de flujos de trabajo o la señalización de anomalías”, añade. “Este enfoque genera confianza en la organización y demuestra el retorno de la inversión sin exponer en exceso a la empresa a riesgos relacionados con los datos”.

Limpiar el almacenamiento

En lo que respecta a las prácticas de almacenamiento de datos, no hay duda de que las organizaciones necesitan poner orden. Las malas prácticas conducen a una mala calidad de los datos, lo que podría afectar a los proyectos impulsados por la IA.

“Las escuelas suelen ser muy buenas almacenando datos en un trastero donde simplemente siguen tirando cajas sin mirar dentro”, afirma Friend. “Cualquiera que haya pasado por una renovación tecnológica sabe que un almacenamiento desordenado supone una enorme carga financiera”.

Décadas de malas prácticas de recopilación “han creado una deuda técnica que ya no podemos ignorar”, afirma Friend. “Puede que pienses que tu almacenamiento heredado es inofensivo, pero en realidad supone una enorme carga financiera en forma de costes operativos crecientes” y puede afectar negativamente a las iniciativas de IA.

Google is recasting its data and analytics portfolio as the Agentic Data Cloud, an architecture it says is aimed at moving enterprise AI from pilot to production by turning fragmented data into a unified semantic layer that agents can reason over and act on more reliably at scale.

The new architecture builds on Google’s existing data platform strategy, bringing together services such as BigQuery, Dataplex, and Vertex AI, and elevating their capabilities in metadata, governance, and cross-cloud interoperability into what the company describes as a shared intelligence layer.

That intelligence layer strategy is underpinned by the new Knowledge Catalog, an evolution of Dataplex Universal Catalog, that the company said uses new capabilities to extend its metadata foundation into a semantic layer mapping business meaning and relationships across data sources.

These capabilities include native support for third-party catalogs, applications such as Salesforce, Palantir, Workday, SAP, and ServiceNow, and the option to move third-party data to Google’s lakehouse, which automatically maps the data to Knowledge Catalog.

To capture business logic more directly for data stored inside Google Cloud, the company is adding tools including a LookML-based agent, currently in preview, that can derive semantics from documentation, and a new feature in BigQuery, also in preview, that allows enterprises to embed that business logic for faster data analysis.

Beyond aggregation, the catalog itself is designed to continuously enrich semantic context by analyzing how data is used across an enterprise, senior google executives wrote in a blog post.

This includes profiling structured datasets as well as tagging and annotating unstructured content stored in Google Cloud Storage, the executives pointed out, adding that the catalog’s underlying system can also infer missing structure in data by  using its Gemini models to generate schemas and identify relationships.

Turning data into business context the next battleground for AI

For analysts, Google’s focus on semantics targets one of the biggest barriers to production AI for enterprises.

“The hardest AI problem is inconsistent meaning,” said Dion Hinchcliffe, lead of the CIO practice at The Futurum Group, noting that a unified semantic layer could help CIOs establish consistent business context across systems while reducing the need for developers to manually stitch together metadata and lineage.

That focus on semantic context also reflects a broader shift in how hyperscalers are approaching enterprise AI. Microsoft with Fabric IQ and AWS with Nova Forge are pursuing similar strategies, building semantic context layers over enterprise data to make AI systems more consistent and easier to operationalize at scale.

While Microsoft’s approach is to wrap AI applications and agents with business context and semantic intelligence in its Fabric IQ and Work IQ offerings, AWS want enterprises to blend business context into a foundational LLM by feeding it their proprietary data.

Mike Leone, principal analyst at Moor Insights and Strategy, said Google’s approach, though closer to Microsoft’s, places the data gravity one layer above the lakehouse, within its data catalog and semantic graph capabilities.

“Google and Microsoft are solving the same problem from different angles, Fabric through a unified data foundation and Google through a unified semantic and context layer,” Leone said.

Even data analytics software vendors are converging on the idea of offering a catalog that can map semantic context from a variety of data sources, Leone added, pointing to Databricks’ Unity Catalog and Snowflake’s Horizon Catalog.

Semantic accuracy could pose challenges for CIOs

However, Google’s approach to building an intelligent semantic layer, especially its evolved Knowledge Catalog, comes with its own set of risks for CIOs.

The new catalog’s automated semantic context refinement capability, according to Jim Hare, VP analyst at Gartner, could amplify governance challenges, especially around metadata management: “In complex enterprise domains, errors in inferred relationships or definitions will require ongoing human domain oversight to maintain trust.”

Hare also warned of operational and cost management challenges.

“Agent-driven workflows spanning analytical and operational data, potentially across clouds, will introduce new challenges in observability, debugging, and cost predictability,” he said. “Dynamic agent behavior can generate opaque consumption patterns, requiring chief data and analytics officers (CDAOs) to closely manage cost attribution, usage limits, and operational guardrails as these capabilities mature.”

Adopting Google’s new architectural approach could increase dependence at the orchestration layer, resulting in issues around portability, he warned: “Exiting Google-managed semantics, Gemini agents, or BigQuery abstractions may be harder than migrating data alone.”

Bi-directional federation as strategic play

Even so, the trade-offs may be acceptable for enterprises prioritizing tighter data integration over flexibility.

As part of the new architecture, Google is also offering cross-platform data interoperability via the Apache Iceberg REST Catalog that it says will allow bi-directional federation, in turn letting enterprises access, query, and govern data across environments such as Databricks, Snowflake, and AWS without requiring data movement or cost in egress fees.

For Stephanie Walter, practice leader of the AI stack at HyperFRAME Research, this interoperability will be strategically important for enterprises scaling agents in production, especially ones that have heterogenous data environments.

Moor Insights and Strategy’s Leone, though, sees it as a different strategic play to address enterprises’ demand to access Databricks, Snowflake, and hyperscaler environments without costly data movement.

Google’s Agentic Data Cloud architecture also includes a Data Agent Kit, currently in preview, which the company says is designed to help enterprises build, deploy, and manage data-aware AI agents that can interact with governed datasets, apply business logic, and execute workflows across systems.

Robert Kramer, managing partner at KramerERP, said the Data Agent Kit will help data practitioners abstract t daily tasks, in turn lowering the barrier to operationalizing agentic AI across workflows.

However, Gartner’s Hare warned that enterprises should guard against over delegating critical data management decisions to automated agents without sufficient observability, validation controls, and human review, particularly where downstream AI systems depend on these agents for continuous data operations.

This article first appeared on InfoWorld.

As every CIO knows, AI success hinges on rock-solid data practices. But as CEOs and boards have emphasized digital transformations in recent years, funding for data management transformation efforts has been piecemeal at best. Now, with AI atop the CEO agenda, many CIOs find themselves in a bind, having to also overhaul data operations and address years, or decades, of accumulated data debt.   

If your enterprise has data debt, AI will expose it. In fact, data debt can lead to devastating failure rates with AI projects. For technology leaders, there’s no time like the present to pay down this debt with a comprehensive remediation strategy.

Data debt can arise for a variety of reasons, including old and outdated data management practices, shortcuts and compromises in infrastructure to meet near-term goals, poorly documented data sources, and inefficient data storage practices.

Research firm IDC in its 2026 CIO Agenda Predictions notes that by 2027, CIOs who delay the launch of data debt remediation will face 50% higher AI failure rates and rising costs, as model underperformance exposes issues from siloed, redundant, or poor-quality data.

“These findings reinforce that scaling AI requires disciplined investment in data foundations and integrated platforms, and that postponing these fundamentals risks turning AI ambition into sustained operational friction,” the report says.

“AI doesn’t create data problems; it exposes and accelerates them,” says Hrishikesh Pippadipally, CIO at accounting and advisory firm Wiss. “When organizations lack standardized processes, consistent definitions, and disciplined data governance, data naturally decays over time. That decay may not be visible in traditional reporting environments, but AI systems surface those inconsistencies quickly.”

Data debt is often the result of process drift — multiple teams using different definitions, inconsistent data entry standards, and siloed systems evolving independently, Pippadipally says.

“Without standardization and clear ownership, even modern systems degrade,” he says. “At our organization, we’ve learned that remediation isn’t just about cleaning historical data. It’s about instituting disciplined processes that prevent decay going forward: clear data ownership, standardized workflows, and governance embedded into daily operations.”

That said, not all AI initiatives are blocked by imperfect data, Pippadipally says. “There are smaller, well-bounded use cases, such as document summarization, drafting assistance, anomaly flagging, or reconciliation support, that can deliver value with human-in-the-loop verification,” he says. “These contained applications allow organizations to build AI maturity while foundational data improvements are under way.”

A mounting problem that requires a fast fix

A widespread problem, data debt at most organizations has grown organically over decades. In addition to increasing emphasis on data collection, companies have also accumulated data debt over years of mergers and acquisitions, as well as the deployment of new systems and services either enterprisewide or by departments.

“Systems were layered in response to immediate needs, acquisitions, regulatory requirements, or departmental preferences,” Pippadipally says. “Over time, inconsistent processes and standards lead to fragmented data environments.”

Moreover, data management inefficiencies have historically been addressed with manual work-arounds, Pippadipally says. “Teams reconciled reports manually,” he says. “Analysts compensated for inconsistent definitions. But AI reduces tolerance for ambiguity. When automated systems operate at scale, inconsistencies multiply rather than average out.”

It’s vital to address this now because AI initiatives are moving faster than process maturity. There is a clear sense of urgency.

“If organizations don’t institutionalize process discipline and standardization, they risk automating chaos instead of improving outcomes,” Pippadipally says. “The issue is not simply poor data; it is the absence of sustained governance to keep data reliable over time.”

For many enterprises, data debt can stay hidden while they are conducting traditional business intelligence or one-off analytics, says Juan Nassif, regional CTO at software development provider BairesDev.

“AI is different; it’s far less forgiving and it quickly exposes duplicates, inconsistent definitions, missing context, and ‘mystery fields’ with unclear lineage,” Nassif says. “When you scale beyond pilots, those issues show up as model underperformance, higher iteration cycles, and rising operational costs. It’s absolutely a concern for us, too, and we treat it as a prerequisite for scaling AI responsibly.”

If data is incomplete, inconsistent, or duplicated, the output from AI models becomes unreliable. “That can mean wrong answers, poor recommendations, or automations that break at the worst time,” Nassif says. “Teams end up spending most of their time wrangling data, reworking pipelines, and compensating for poor inputs with repeated tuning and exceptions.”

Some form of data debt is present in every sector, and in virtually all sizes of organizations.

“I witness the consequences of data debt in my daily work with schools in the UK every single week,” says Mark Friend, director of Classroom365, which consults educational institutions on technology and architecture and strategies.

“Most people assume that when they purchase the latest AI tool, all their problems will be solved no matter how messy the foundation underneath the hood,” Friend says. “My experience with this is that even the most expensive software is useless if the input is not reliable.” Data debt is “a fundamental risk to institutional stability,” he says.

Tips for effective data debt remediation

Enterprise-wide data debt remediation can be a significant, costly undertaking that involves multiple aspects of the business. It’s not just a technology issue, but a discipline issue as well. It requires cleaning up historical data as well as strengthening process governance to keep from repeating the mistakes or poor practices of the past.

Because of this, building and executing an effective strategy requires an organized and thorough approach. Here are some tips from experts.

Get senior management and board-level sponsorship

Any major IT initiative typically needs buy-in from senior business executives and even boards, particularly if it involves a large, global enterprise. Data debt remediation is no different. There is significant financial risk if remediation does not have the blessing and full backing of senior executives and board members.

Explaining the potential ramifications is a good way to bring attention to the need for remediation. “Make data debt visible and tie it to business risk,” Nassif says. “Data debt won’t get prioritized until it’s linked to AI failure rates, rising costs, and compliance exposure.”

Data debt is now a board-level risk, says Adrian Lawrence, founder of executive recruitment firm NED Capital, who advises boards and finance leaders on enterprise data governance, reporting integrity, and AI readiness.

“I see the pressure mounting with boards linking their AI investment to productivity and profitability objectives, but disjointed financial, sales, and operations data severely undermine model accuracy,” Lawrence says. “They lay bare the deficiencies [enterprise platform] upgrades and antiquated technology did not fully address.”

Success with debt remediation “demands executive sponsorship, disciplined data governance, and staged architecture cleanup treating data as an asset on the balance sheet,” Lawrence says.

Standardize core processes before scaling AI

To make the benefits of data debt remediation more long lasting, enterprises need to standardize their core business processes.

“Data quality reflects process quality,” Pippadipally says. “Leaders must align on standardized workflows, definitions, and system usage before expecting AI to operate consistently. Without process standardization, remediation efforts will be temporary.”

AI performs best in predictable environments, Pippadipally says, and standardization creates the stability AI requires.

BairesDev has embedded automated checks for data freshness, completeness, duplicates, and schema changes, so data quality issues get caught before they reach analytics or AI workflows, Nassif says.

Establish data ownership and ongoing governance

Another way to assure long-term benefits from a remediation effort is to have ongoing governance and accountability processes in place.

“Data remediation is not a one-time cleanup initiative,” Pippadipally says.

“Assigning clear ownership at the domain level, and establishing continuous monitoring, prevents data from degrading again.”

This is important, because governance ensures sustainability. “Without discipline, organizations reaccumulate data debt even after cleanup efforts,” Pippadipally says.

“We’ve been tightening dataset ownership and standardizing common business definitions, so teams aren’t training or prompting on conflicting ‘versions of truth,’” Nassif says. “We’ve been strengthening our cataloging and lineage practices, so teams can trace where data comes from, how it transforms, and who can use it — critical for both trust and governance.”

The biggest shift is mindset. “We don’t treat data remediation as a one-time cleanup,” Nassif says. “We treat it as ongoing engineering with guardrails that prevent debt from coming right back.”

Prioritize high-value, contained AI use cases

While large data modernization initiatives progress within an organization, CIOs can deploy AI in tightly scoped areas where outputs are verifiable and human oversight is straightforward, Pippadipally says.

“Examples include drafting support, controlled reconciliations, workflow triage, or anomaly flagging,” Pippadipally says. “This approach builds organizational confidence and demonstrates ROI without overexposing the enterprise to data risk.”

Clean up storage

When it comes to data storage practices, there’s no doubt that organizations need to clean up their act. Poor practices lead to poor data quality, which could impact AI-driven projects.

“Schools are often very good at storing data like [in] an attic where they just keep throwing boxes without looking inside,” Friend says. “Anyone who has lived through a technology refresh knows that messy storage is a massive financial burden.”

Decades of bad collection practices “have created a technical rot that we can no longer ignore,” Friend says. “You might think that your legacy storage is harmless, but it actually places a massive financial burden in the form of rising operational costs,” and can negatively impact AI initiatives.

SAP 파트너 어워드는 한 해 동안 고객의 비즈니스 혁신과 성과 창출에 기여한 글로벌 파트너를 선정하는 프로그램이다. 성과 지표와 데이터 기반 평가를 통해 수상 기업이 결정된다.

오픈텍스트에 따르면, 이번 수상은 ‘파트너 솔루션 성공(Partner Solution Success)’과 ‘인적 자본 관리(Human Capital Management, HCM) 솔루션 우수성(Human Capital Management Solution Excellence)’ 부문에서 이루어졌으며, SAP(SAP) 솔루션 기반 혁신과 고객 가치 창출 성과를 인정받은 결과다. 오픈텍스트는 SAP 솔루션 확장(SAP Solution Extensions) 분야에서의 기술 리더십과 협업 성과를 인정받았다. SAP 환경 내에서 정보관리(Information Management), 콘텐츠(Content), 데이터(Data), AI(Artificial Intelligence) 기능을 통합해 기업의 운영 효율성과 규제 대응 역량을 동시에 강화한 점이 주요 평가 요소로 작용했다.

양사는 협력을 통해 기업이 SAP 기반 비즈니스 프로세스 전반에서 AI 기반 콘텐츠 활용, 자동화(Automation), 클라우드 전환(Cloud Transformation)을 보다 빠르게 추진할 수 있도록 지원하고 있다. 이를 통해 기업은 SAP S/4HANA(SAP S/4HANA) 클라우드 전환 과정에서 복잡성을 줄이고 생산성을 높일 수 있다.


또한 오픈텍스트는 SAP 석세스팩터스(SAP SuccessFactors)와의 통합을 통해 인사(Human Resources, HR) 영역에서도 디지털 문서 관리(Document Management)와 업무 자동화를 지원하고 있으며, 전사적 업무 효율 개선을 돕고 있다.

오픈텍스트 SAP 파트너십 담당 부사장 마크 베일리는 “이번 수상은 SAP와의 긴밀한 협력을 통해 고객의 디지털 전환(Digital Transformation)과 AI 기반 혁신을 실질적으로 지원해 온 성과를 보여준다”라며 “앞으로도 기업이 보다 빠르고 안전하게 AI 시대에 대응할 수 있도록 지원을 확대할 계획”이라고 전했다.

오픈텍스트는 향후에도 SAP와의 협력을 기반으로 클라우드 전환과 AI 활용을 가속화하고, 글로벌 고객의 정보관리와 비즈니스 혁신을 지속 지원할 방침이다.
dl-ciokorea@foundryco.com