BCG research has found that over 70% of digital transformations fail to meet their goals. While digital transformation leaders outperform their competitors to reap the rewards, the typical digital transformation effort flounders on the sheer complexity of using technology to increase a company’s speed and learning at scale.   As initiatives become increasingly complex, the likelihood of a successful outcome goes down.

The reason lies in a growing paradox: technology is advancing exponentially, but the enterprise’s ability to change remains largely fixed. Each new wave of innovation accelerates faster than organizational structures, governance and culture can adapt, creating a widening gap between the speed of technological progress and the pace of enterprise evolution.

Each new wave of innovation demands faster decisions, deeper integration and tighter alignment across silos.  Yet, most organizations are still structured for linear, project-based change. As complexity compounds, the gap between what’s possible and what’s operationally sustainable continues to widen.

The result is a growing adaptation gap — the widening distance between the speed of innovation and the enterprise’s capacity to absorb it. CIOs now sit at the fault line of this imbalance, confronting not only relentless technological disruption but also the limits of their organizations’ ability to evolve at the same pace. The underlying challenge isn’t adopting new technology; it’s architecting enterprises capable of continuous adaptation.

The innovation paradox

Ray Kurzweil’s Law of Accelerating Returns tells us that innovation compounds. Each breakthrough accelerates the next, shrinking the interval between waves of disruption. Where the move from client–server to cloud once took years, AI and automation now reinvent business models in months. Yet most enterprises remain structured around quarterly cycles, annual plans and five-year strategies — linear rhythms in an exponential world.

This mismatch between accelerating innovation and a slow organizational metabolism is the Transformation Trap. It emerges when the enterprise’s capacity to adapt is constrained by a legacy architecture, culture and governance designed for control rather than learning, and accumulated debt that slows down reinvention.

3 structural fault lines

1. Outpaced architecture

Most enterprises were built around periodic reboots aligned to the renewal of new technology, not continuous renewal. Legacy systems and delivery models offer stability but are not resilient to change.  When architecture is treated as documentation rather than a living capability, agility decays. Each new wave of innovation arrives before the last one stabilizes, creating fatigue rather than resilience.

2. Compounding debt

Technical debt has been rapidly amassing in three areas: accumulated (legacy systems, brittle integrations and semantic inconsistencies that have been layered through mergers and upgrades), acquired (trade-offs leaders make in the name of speed such as mergers, platform swaps or modernization sprints that prioritize short-term delivery over long-term coherence.), and emergent (AI, automation and advanced analytics without the suitable frameworks or governance to integrate them sustainably). The result destabilizes transformation efforts. Without a coherent architectural foundation, every modernization effort simply layers new fragility atop the old.

3. Governance built for yesterday

Traditional governance models reward completion, not adaptation. They measure compliance with the plan, not readiness for change. As innovation cycles shorten, this rigidity creates blind spots, slowing reinvention even as investment increases.

Why reboots keep failing

Most modernization programs change the surface, not the supporting systems. New digital interfaces and analytics layers often sit atop legacy data logic and brittle integration models. Without rearchitecting the semantic and process foundations, the shared meaning behind data and decisions, enterprises modernize their appearance without improving their fitness.

As companies struggle to keep up with technology innovation, emergent debt will become an increasingly significant challenge: the cost of speed without an underlying architecture. Agile teams move fast but in isolation, creating redundant APIs, divergent data models and inconsistent semantics. Activity replaces alignment. Over time, delivery accelerates, but enterprise coherence erodes as new technologies are adopted on brittle systems.

Governance, meanwhile, remains static. Review boards and compliance gates were built for predictability, not velocity. They create the illusion of control but operate on a delay that makes true adaptation increasingly impossible in our accelerating world.

The CIO’s dilemma

CIOs today stand between two diverging curves: the exponential rise of technology and the linear pace of enterprise adaptation. This gap defines the Transformation Trap. It’s not about delivering more change.  It’s about building systems and structures that can evolve continuously without the start and stop of a project mindset.

The new question is not, ‘How do we transform again?’ but ‘How do we build so we never need to?’ That requires architectures capable of sustaining and sharing meaning across every system and process, which technologists refer to as semantic interoperability. For CIOs, it’s the ability to ensure data, workflows and AI models all speak the same language — enabling trust, agility and decision‑ready intelligence.

CIO insight: Semantic interoperability

The next era of transformation depends on shared meaning across systems. Without it, AI and analytics amplify noise instead of insight. Building semantic interoperability is not just a technical exercise.  It’s the foundation of decision trust, adaptive automation and continuous reinvention.

Leaders like Palantir have unlocked the power of the Palantir Foundry platform to demonstrate what’s possible when data from thousands of systems is unified through a shared ontology. In platforms like Foundry, meaning becomes the connective tissue that links operational reality to executive insight, enabling enterprises to reason, predict and act with confidence.

For CIOs, this is the next frontier: not just integrating systems but integrating understanding.

5 imperatives for continuous change

1. Make governance a living system. Governance must evolve from control to continuity. Instrument your enterprise with telemetry and policy‑as‑code guardrails that guide rather than gate. Governance should act like a gyroscope, stabilizing the course while enabling movement.
2. Treat architecture as the enterprise’s metabolism. Architecture is not a static blueprint; it’s a living system that must refresh continuously. Embed architects directly in delivery teams. Evolve models and ontologies alongside code. A healthy enterprise architecture metabolizes change rather than resists it.
3. Measure system fitness, not project velocity. Stop measuring completion speed and start measuring adaptability. Track how quickly your organization can absorb new technologies without needing a reboot. Key indicators include shorter time‑to‑adapt, fewer redundant integrations and higher semantic interoperability across systems.
4. Cultivate a bold learning culture. Continuous change requires continuous learning. Foster a culture that rewards curiosity, experimentation and the courage to retire what no longer works. Encourage teams to test, learn and share insights quickly, turning every iteration into institutional wisdom. Boldness in adopting what works, and humility in letting go of what doesn’t, is the human engine of transformation.  Don’t neglect architectural understanding in the race to learn new technologies.
5. Orchestrate intent through continuous feedback. Today’s enterprise requires constant calibration between intent and impact.  Build a feedback architecture that senses, interprets and responds in real-time — linking business objectives to operational signals and system behavior. This creates a dynamic enterprise that doesn’t just execute plans but continuously evolves its direction through insight. Feedback becomes the compass that turns movement into momentum.

A closing reflection

Kurzweil’s law tells us the future accelerates exponentially, but enterprises still plan in straight lines. Transformation cannot remain episodic; it must become a living process of continuous design. CIOs are now the custodians of continuity, tasked with building architectures that learn, evolve and adapt at the speed of change.

In a world where technology doubles, only architecture that evolves continuously both semantically and operationally can endure. 

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

A few years ago, a model we had integrated for customer analytics produced results that looked impressive, but no one could explain how or why those predictions were made. When we tried to trace the source data, half of it came from undocumented pipelines. That incident was my “aha” moment. We didn’t have a technology problem; we had a truth problem. I realised that for all its power, AI built on blind faith is a liability.

This experience reshaped my entire approach. As artificial intelligence becomes central to enterprise decision-making, the “truth problem,” whether AI outputs can be trusted, has become one of the most pressing issues facing technology leaders. Verifiable AI, which embeds transparency, auditability and formal guarantees directly into systems, is the breakthrough response. I’ve learned that trust cannot be delegated to algorithms; it has to be earned, verified and proven.

The strategic urgency of verifiable AI

AI is now embedded in critical operations, from financial forecasting to healthcare diagnostics. Yet as enterprises accelerate adoption, a new fault line has emerged: trust. When AI decisions cannot be independently verified, organisations face risks ranging from regulatory penalties to reputational collapse.

Regulators are closing in. The EU AI Act, NIST AI Risk Management Framework and ISO/IEC 42001 all place accountability for AI behavior directly on enterprises, not vendors. A 2025 transparency index has found that leading AI model developers scored an average of 37 out of 100 on disclosure metrics, highlighting the widening gap between capability and accountability.

For me, this means verifiable AI is no longer optional. It is the foundation for responsible innovation, regulatory readiness and sustained digital trust.

The 3 pillars of a verifiable system

Verifiable AI transforms “trust” from a matter of faith into a provable, measurable property. It involves building AI systems that can demonstrate correctness, fairness and compliance through independent validation. In my career, I’ve seen that if you cannot show how your model arrived at a decision, the technology adds risk instead of reducing it. This practical verifiability spans three pillars.

1. Data provenance: Ensuring all training and input data can be traced, validated and audited

In one early project back in 2017, we worked with historic trading data to train a predictive model for payment analytics. It looked solid on the surface until we realized that nearly 20 percent of the dataset came from an outdated exchange feed that had been quietly discontinued. The model performed beautifully in backtesting, but failed in live trading conditions.

This incident was a wake-up call that data provenance is not about documentation; it is about risk control. If you cannot prove where your data comes from, you cannot defend what your model does. This principle of reliable data sourcing is a cornerstone of the NIST AI Risk Management Framework, which has become an essential guide for our governance

2. Model integrity: Verifying that models behave as intended under specified conditions

In another project, a fraud detection system performed perfectly during lab simulations but faltered in production when user behavior shifted after a market event. The underlying model was never revalidated in real time, so its assumptions aged overnight.

This taught me that model integrity is not a task completed at deployment but an ongoing responsibility. Without continuous verification, even accurate models lose relevance fast. We now use formal verification methods, borrowed from aerospace and defense, that mathematically prove model behavior under defined conditions.

3. Output accountability: Providing clear audit trails and explainable decisions

When we introduced explainability dashboards into our AI systems, something unexpected happened. Compliance, engineering and business teams started using the same data to discuss decisions. Instead of debating outcomes, they examined how the model reached them.

Making outputs traceable turned compliance reviews from tense exercises into collaborative problem-solving. Accountability does not slow innovation; it accelerates understanding.

These principles mirror lessons from another domain I have worked in: blockchain, where verifiability and auditability have long been built into the system’s design.

What blockchain infrastructure taught me about AI verification

My background in building blockchain-based payment systems fundamentally shaped how I approach AI verification today. The parallel between payment systems and AI systems is more direct than most technology leaders realize.

Both make critical decisions that affect real operations and real money. Both processes transact too quickly for humans to review individually. Both require multiple stakeholders, customers, regulators and auditors to trust outputs they cannot directly observe. The key difference is that we solved the verification problem for payments more than a decade ago, while AI systems continue to operate as black boxes.

When we built payment infrastructure, immutable blockchain ledgers created an unbreakable audit trail for every transaction. Customers could independently verify their payments. Merchants could prove they received funds. Regulators could audit everything without accessing private data. The system wasn’t just transparent, and it was cryptographically provable. Nobody had to take our word for it.

This experience revealed something crucial: trust at scale requires mathematical proof, not vendor promises. And that same principle applies directly to AI verification.

The technical implementation is more straightforward than many enterprises assume. Blockchain infrastructure or simpler append-only logs can document every AI inference, what data went in, what decision came out and what model version processed it. Research from the Mozilla Foundation on AI transparency in practice confirms that this kind of systematic audit trail is exactly what most AI deployments lack today.

I’ve seen enterprises implement this successfully across regulated industries. GE Healthcare’s Edison platform includes model traceability and audit logs that enable medical staff to validate AI diagnoses before applying them to patient care. Financial institutions like JPMorgan use similar frameworks, combining explainability tools like SHAP with immutable audit records that regulators can inspect and verify.

The infrastructure exists. Cryptographic proofs and trusted execution environments can ensure model integrity while preserving data privacy. Zero-knowledge proofs allow verification that an AI model operated correctly without exposing sensitive training data. These are mature technologies, borrowed from blockchain and applied to AI governance.

For technology leaders evaluating their AI strategy, the lesson from payments is simple: treat AI outputs like financial transactions. Every prediction should be logged, traceable and independently verifiable. This is not optional infrastructure. It is foundational to any AI deployment that faces regulatory scrutiny or requires stakeholder trust at scale.

A leadership playbook for verifiable AI

Each of those moments, discovering flawed trading data, watching a model lose integrity and seeing transparency unite teams, shaped how I now lead. They taught me that verifiable AI is not just technical architecture, it is organisational culture. Here is the playbook that has worked for me.

• Start with an AI audit and risk assessment. Our first step was to inventory every AI use case across the business. We categorized them by potential impact on customers, operations and compliance. A high-risk system, like one used for financial forecasting, now demands the highest level of verifiability. This triage allowed us to focus our efforts where they matter most.
• Make verifiability a non-negotiable criterion. We completely changed our procurement process. When evaluating an AI vendor, we now have a checklist that goes far beyond cost and performance. We demand evidence of their model’s traceability, documentation on training data and their methodology for ongoing monitoring. This shift fundamentally changed our vendor conversations and raised transparency standards across our ecosystem.
• Build a culture of skepticism and accountability. One of our most crucial changes has been cultural. We actively train our staff to question AI outputs. I tell them that a red flag should go up if they can’t understand or challenge an AI’s recommendation. This human-in-the-loop principle is our ultimate safeguard, ensuring that AI assists human judgment rather than replacing it.
• Invest in the right infrastructure. Building verifiable AI requires investment in data pipelines, lineage tracking and real-time monitoring platforms. We use model monitoring and transparency dashboards that catch drift and bias before they become compliance violations. These platforms aren’t optional — they’re foundational infrastructure for any enterprise deploying AI at scale.
• Translate compliance into design from the start. I used to view regulatory compliance as a final step. Now, I see it as a primary design input. By translating the principles of regulations into technical specifications from day one, we ensure our systems are built to be transparent. This is far more effective and less costly than trying to retrofit explainability onto a finished product.

The path forward: From intelligence to integrity

The future of AI is not only about intelligence, it’s also about integrity. I’ve learned that trust in AI does not scale automatically; it must be designed, tested and proven every day.

Verifiable AI protects enterprises from compliance shocks, builds stakeholder confidence and ensures AI systems can stand up to public, legal and ethical scrutiny. It is the cornerstone of long-term digital resilience.

For any technology leader, the next competitive advantage will not come from building faster AI, but from building verifiable AI. In the next era of enterprise innovation, leadership won’t be measured by how much we automate, but by how well we can verify the truth behind every decision.

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

病院と企業がAI診断支援を開発するケース

まず典型的なシナリオとして、病院とAIスタートアップが共同で診断支援システムを開発するケースを考えてみます。ここで鍵になるのは、このプロジェクトを「病院の業務の一部としての委託」と位置づけるのか、「病院から企業への第三者提供」と位置づけるのかという点です。前者であれば、病院が自院の診療の質を高めるためにAIを導入し、そのモデル開発を受託者としての企業が支援する構図になります。この場合、データの利用目的は診療の高度化であり、個人情報保護法上の委託として整理できることが多いと言えます。

一方、企業側が将来的に他の医療機関にも販売する汎用的なAI製品の開発を主目的としている場合、病院から見れば、自院の患者データが事実上「企業の自社事業」に活用されていることになります。この場合、単純な委託ではなく、病院から企業への第三者提供と評価される余地があり、患者の同意や次世代医療基盤法の枠組みの活用など、より厳格な法的根拠が求められます。どちらに当たるかは、契約書の文言だけでなく、実際のデータフローや開発スキームの実態に基づいて判断されるべきです。

こうしたグレーゾーンを放置したままプロジェクトを進めると、後に患者からの問い合わせやメディア報道があった際に、説明がつかなくなるリスクがあります。そのため、病院と企業は、プロジェクト開始前の段階で、法務・情報システム・現場の医師などを交えた形でスキームを明確化し、必要であれば倫理審査やオプトアウト掲示、追加同意の取得などの措置を講じておくことが望まれます。

製薬企業のリアルワールドデータ活用と次世代医療基盤法

製薬企業や医療機器メーカーが、薬の有効性や安全性を評価するために、実臨床でのデータを活用する動きも広がっています。ここで有力な選択肢の一つになるのが、次世代医療基盤法に基づく匿名加工・仮名加工医療情報の利用です。企業が認定利用事業者としての認定を受け、認定作成事業者から加工済データの提供を受けるルートを取れば、個々の医療機関から直接同意を取得することなく、大規模でバイアスの少ないデータセットを利用できる可能性が開けます。

ただし、ここでも課題は少なくありません。例えば、仮名加工医療情報を用いた精密な解析は、患者のフォローアップや追加情報の取得が技術的に可能であることから、再識別リスクへの配慮が一段と重要になります。また、企業がAIモデルを学習させ、そのモデルを他の用途に再利用する場合、当初の利用目的との整合性や、患者への説明との関係が問題になります。モデル自体に個人情報性がどこまで残るのかという技術的な論点も含め、法務・コンプライアンスだけではなく、データサイエンスの専門家との協議が不可欠です。

さらに、製薬企業が次世代医療基盤法ルートを取るのか、それとも個別の医療機関との連携によるオプトイン型のデータ提供契約を選ぶのか、といった戦略的な選択もあります。前者はスケールメリットが大きい一方で、データ利用の柔軟性に一定の制約がかかり、後者は柔軟性が高い反面、データ収集の手間とバイアスの問題を伴います。企業ごとに、研究開発ポートフォリオやリスク許容度、社会的な説明責任へのスタンスに応じて、最適な組み合わせを模索していくことになるでしょう。

患者の信頼をどう確保するか

どれだけ法的な要件を満たしていても、患者が「知らないうちに自分のデータが使われている」と感じてしまえば、医療データ活用そのものへの信頼は揺らぎます。今後の医療データ政策にとって最も重要なのは、法令遵守を前提としつつ、その上で「どこまで透明性を高められるか」という視点です。具体的には、自院や企業のWebサイト、待合室のパンフレット、診察室での医師の説明など、さまざまな接点を通じて、データの利用目的や提供先、患者に開かれた権利（開示請求・訂正請求・利用停止の申し出など）を伝えていく取り組みが求められます。

また、患者代表や市民参加型の検討会を設置し、政策レベルでの議論に生活者の声を反映させることも重要です。データヘルス改革や医療DXに関する政府の資料には、国民の理解と納得を得ることの重要性が繰り返し強調されていますが、それを具体的なプロセスに落とし込むことはまだ道半ばです。

最終的に、医療データ活用の成否を決めるのは、制度の巧妙さだけではありません。現場の医療者が患者の不安に丁寧に向き合い、企業が短期的なビジネス利益にとらわれず、長期的な信頼関係の構築を重視できるかどうか。そして、患者自身が自分のデータの価値を理解し、主体的にその活用に参加できる環境を整えられるかどうか。その総体として、日本の医療データ法制がどのような「文化」を形づくるのかが、これからの数十年を左右していくはずです。

A year ago, agentic AI lived mostly in pilot programs. Today, CIOs are embedding it inside customer-facing workflows where accuracy, latency, and explainability matter as much as cost.

As the technology matures beyond experimentation, the build-versus-buy question has returned with urgency, but the decision is harder than ever. Unlike traditional software, agentic AI is not a single product. It’s a stack consisting of foundation models, orchestration layers, domain-specific agents, data fabrics, and governance rails. Each layer carries a different set of risks and benefits.

CIOs can no longer ask simply, “Do we build or do we buy?” They must now navigate a continuum across multiple components, determining what to procure, what to construct internally, and how to maintain architectural flexibility in a landscape that changes monthly.

Know what to build and what to buy

Matt Lyteson, CIO of technology transformation at IBM, begins every build-versus-buy decision with a strategic filter: Does the customer interaction touch a core differentiator? If the answer is yes, buying is rarely enough. “I anchor back to whether customer support is strategic to the business,” he says. “If it’s something we do in a highly specialized way — something tied to revenue or a core part of how we serve clients — that’s usually a signal to build.”

IBM even applies this logic internally. The company uses agentic AI to support employees, but those interactions rely on deep knowledge of a worker’s role, devices, applications, and historical issues. A vendor tool might address generic IT questions, but not the nuances of IBM’s environment.

However, Lyteson cautions that strategic importance isn’t the only factor. Velocity matters. “If I need to get something into production quickly, speed may outweigh the desire to build,” he says. “I might accept a more generic solution if it gets us value fast.” In practice, that means CIOs sometimes buy first, then build around the edges, or eventually build replacements once the use case matures.

Another useful insight can be taken from Wolters Kluwer, where Alex Tyrrell, CTO of health, runs experiments early in the decision process to test feasibility. Rather than committing to a build-or-buy direction too soon, his teams quickly probe each use case to understand whether the underlying problem is commodity or differentiating.

“You want to experiment quickly to understand how complex the problem really is,” he says. “Sometimes you discover it’s more feasible to buy and get to market fast. Other times, you hit limits early, and that tells you where you need to build.”

Tyrrell notes that many once-specialized tasks — OCR, summarization, extraction — have been commoditized by advances in gen AI. These are better bought than built. But the higher-order logic that governs workflows in healthcare, legal compliance, and finance is a different story. Those layers determine whether an AI response is merely helpful or genuinely trusted.

That’s where the in-house build work begins, says Tyrrell. And it’s also where experimentation pays for itself since quick tests reveal very early whether an off-the-shelf agent can deliver meaningful value, or if domain reasoning must be custom-engineered.

Buyer beware

CIOs often assume that buying will minimize complexity. But vendor tools introduce their own challenges. Tyrrell identifies latency as the first trouble spot. A chatbot demo may feel instantaneous, but a customer-facing workflow requires rapid responses. “Embedding an agent in a transactional workflow means customers expect near-instant results,” he says. “Even small delays create a bad experience, and understanding the source of latency in a vendor solution can be difficult.”

Cost quickly becomes the second shock. A single customer query might involve grounding, retrieval, classification, in-context examples, and multiple model calls. Each step consumes tokens, and vendors often simplify pricing in their marketing materials. But CIOs only discover the true cost when the system runs at scale.

Then comes integration. Many solutions promise seamless CRM or ticketing integration, but enterprise environments rarely fit the demo. Lyteson has seen this play out. “On the surface it looks like plug-and-play,” he says. “But if it can’t easily connect to my CRM or pull the right enterprise data, that’s more engineering, and that’s when buying stops looking faster.”

These surprises are shifting how CIOs buy AI. Instead of purchasing static applications, they increasingly buy platforms — extensible environments in which agents can be orchestrated, governed, and replaced.

Remember the critical roles of data architecture and governance

Most IT leaders have figured out the crucial role of data in making AI work. Razat Gaurav, CEO of software company Planview, compares enterprise data to the waters of Lake Michigan: abundant, but not drinkable without treatment. “You need filtration — curation, semantics, and ontology layers — to make it usable,” he says. Without that, hallucinations are almost guaranteed.

Most enterprises operate across dozens or hundreds of systems. Taxonomies differ, fields drift, and data interrelationships are rarely explicit. Agentic reasoning fails when applied to inconsistent or siloed information. That’s why vendors like Planview and Wolters Kluwer embed semantic layers, graph structures, and data governance into their platforms. These curated fabrics allow agents to reason over data that’s harmonized, contextualized, and access-controlled.

For CIOs, this means build-versus-buy is intimately tied to the maturity of their data architecture. If enterprise data is fragmented, unpredictable, or poorly governed, internally built agents will struggle. Buying a platform that supplies the semantic backbone may be the only viable path.

Lyteson, Tyrrell, and Gaurav all stressed that AI governance consisting of ethics, permissions, review processes, drift monitoring, and data-handling rules must remain under CIO control. Governance is no longer an overlay, it’s an integral part of agent construction and deployment. And it’s one layer CIOs can’t outsource.

Data determines feasibility, but governance determines safety. Lyteson describes how even benign UI elements can cause problems. A simple thumbs up or down feedback button may send the full user prompt, including sensitive information, to a vendor’s support team. “You might approve a model that doesn’t train on your data, but then an employee clicks a feedback button,” he says. “That window may include sensitive details from the prompt, so you need governance even at the UI layer.”

Role-based access adds another challenge. AI agents can’t simply inherit the permissions of the models they invoke. If governance isn’t consistently applied through the semantic and agentic layers, unauthorized data may be exposed through natural-language interactions. Gaurav notes that early deployments across the industry saw precisely this problem, including cases where a senior executive’s data surfaced in a junior employee’s query.

Invest early in an orchestration layer, your new architectural centerpiece

The most striking consensus across all three leaders was the growing importance of an enterprise-wide AI substrate: a layer that orchestrates agents, governs permissions, routes queries, and abstracts the foundation model.

Lyteson calls this an opinionated enterprise AI platform, a foundation to build and integrate AI across the business. Tyrrell is adopting emerging standards like MCP to enable deterministic, multi-agent interactions. Gaurav’s connected work graph plays a similar role inside Planview’s platform, linking data, ontology, and domain-specific logic.

This orchestration layer does several things that neither vendors nor internal teams can achieve alone. It ensures agents from different sources can collaborate and provides a single place to enforce governance. Moreover, it allows CIOs to replace models or agents without breaking workflows. And finally, it becomes the environment in which domain agents, vendor components, and internal logic form a coherent ecosystem.

With such a layer in place, the build-versus-buy question fragments, and CIOs might buy a vendor’s persona agent, build a specialized risk-management agent, purchase the foundation model, and orchestrate everything through a platform they control.

Treat the decision to build vs buy as a process, not an event

Gaurav sees enterprises moving from pilots to production deployments faster than expected. Six months ago many were experimenting, but now they’re scaling. Tyrrell expects multi-partner ecosystems to become the new normal, driven by shared protocols and agent-to-agent communication. Lyteson believes CIOs will increasingly manage AI as a portfolio, constantly evaluating which models, agents, and orchestration patterns deliver the best results for the lowest cost.

Across these perspectives, it’s clear build-versus-buy won’t disappear, but it will become a continuous process rather than a one-time choice.

In the end, CIOs must approach agentic AI with a disciplined framework. They need clarity about which use cases matter and why, and must begin with small, confident pilots, and scale only when results are consistent. They should also build logic where it differentiates, buy where commoditization has already occurred, and treat data curation as a first-class engineering project. It’s important as well to invest early in an orchestration layer that harmonizes agents, enforces governance, and insulates the enterprise from vendor lock-in.

Agentic AI is reshaping enterprise architecture, and the successful deployments emerging today aren’t purely built or purely bought — they’re assembled. Enterprises are buying foundation models, adopting vendor-provided domain agents, building their own workflows, and connecting everything under shared governance and orchestration rails.

The CIOs who succeed in this new era won’t be the ones who choose build or buy most decisively. They’ll be the ones who create the most adaptable architecture, the strongest governance, and the deepest understanding of where each layer of the AI stack belongs.

As chief digital and technology officer for GSK, Shobie Ramakrishnan is helping one of the world’s most science-driven companies turn digital transformation into a force for human health and impact. Drawing on her deep experience in both biotech and high-tech companies, Ramakrishnan has led the transformation of GSK’s capabilities in digital, data, and analytics and is playing a pivotal role in establishing a more agile operating model by reimagining work.

In today’s fast-paced and disruptive environment, expectations on CIOs have never been higher — and the margin for error has never been smaller. In a recent episode of the Tech Whisperers podcast, Ramakrishnan shared her insights on how to capitalize on IT’s rapid evolution and lead change that lasts.

With new tools, data, and capabilities spurring new opportunities to accelerate innovation, CIOs have entered what Ramakrishnan calls a high-friction, high-stakes leadership moment. She argues that the decisions IT leaders make today will determine whether they will be successful tomorrow. With so much hinging on the quality and speed of those decisions, she believes IT leaders must create the conditions for confident, high-velocity decision-making. After the show, we spent time focusing on what could be the new currency of leadership: decision intelligence. What follows is that conversation, edited for length and clarity.

Dan Roberts: In an era where AI is reshaping the fabric of decision-making, how will leaders navigate a world where choices are co-created with intelligent systems?

Shobie Ramakrishnan: Decision-making in the age of AI will be less about control and more about trust — trust in systems that don’t just execute, but reason, learn, and challenge assumptions. For decades, decision-making in large organizations has been anchored in deterministic workflows and, largely, human judgment that’s supported by a lot of analytics. Machines provide the data, and people make the decisions and typically control the process. That dynamic is changing, and as AI evolves from insight engines to reasoning partners, decisions will no longer be static endpoints. They’ll become iterative, adaptive, and co-created. Human intuition and machine intelligence will operate in fast feedback loops, each learning from the other to refine outcomes.

This shift demands a new leadership mindset, moving from command-and-decide to orchestrate-and-collaborate. It’s not about surrendering authority; it’s about designing systems where transparency, accountability, and ethical guardrails can enable trust at scale. The opportunity is really profound here to rewire decision-making so it’s not just faster, but fundamentally smarter and more resilient. Leaders who embrace this will unlock competitive advantage, and those who cling to control risk being left behind in a world where decisions are definitely no longer going to be made by humans alone.

In the past, decision-making was heavily analytical, filled with reports and retrospective data. How do you see the shift from analysis paralysis to decision intelligence, using new tools and capabilities to bring clarity and speed instead of friction and noise?

Decision-making has long been data-enabled and human-led. What’s emerging with the rise of reasoning models and multimodal AI is the ability to run thousands of forward simulations, in minutes or days sometimes, that can factor in demand shocks, price changes, regulatory shifts, and also using causal reasoning, not just correlation. This opens the door to decisions that are data-led with human experts guiding and shaping outcomes.

In situations I call high-stakes, high-analytics, high-friction use cases or decisions, like sales or supply chain forecasting, or in our industry, decisions around which medicines to progress through the pipeline, there is intrinsic value in making these decisions more precise and making them quicker. The hard part is operationalizing this shift, because it means moving the control point from a human-centered fulcrum to a fluid human-AI collaboration. That’s not going to be easy. If changing one personal habit is hard, you can imagine how rewiring decades of organizational muscle memory — especially for teams whose identity has been built around gathering data, developing insights, and mediating decisions — is going to be when multiple functions, complex, conflicting data sets, and enormous consequences collide. The shift will feel even more daunting.

But this is exactly where the opportunity lies. AI can act as an analyst, a researcher, an agent, a coworker who keeps on going. And it can enrich human insights while stripping away human bias. It can process conflicting data at scale, run scenario simulations, and surface patterns that human beings can’t see, all without replacing judgment or control in the end. This isn’t going to be about removing people; it’s about amplifying that ability to make better calls under pressure.

The final thing I would say is that, historically, in a world of haves and have nots, the advantage has always belonged to the haves, those with more resources and more talent. I think AI is going to disrupt that dynamic. The basis of competition will shift to those who master these human-AI decision ecosystems, and that will separate winners from losers in the next decade plus.

Many organizations still operate in a climate of hesitation, often due to fear of being wrong, unclear accountability, or endless consensus-building. How do you create a culture where people feel empowered and equipped to make decisions quickly and with confidence?

Confident decision-making starts with clarity. I can think of three practical shifts that would be valuable, and I still work hard at practicing them. The first one is to narrow the field so you can move faster, because big decisions often stall because we are juggling too many variables or options at once. Amid a lot of complexity, shrinking the scope and narrowing the focus to essential variables or factors that matter forces both clarity and momentum in decision-making. So focus on the few aspects of the decision that matter most and learn to let go of the rest. In the world we are going into where we will have 10x the volume of ideas at 10x the speed, precision has definite advantage over perfection.

The second tip is about treating risk as a dial and not as a switch. What I mean by that is to recognize that risk isn’t binary; it’s a spectrum that leaders need to calibrate and take positions on, based on where you are in your journey, who you are as a company, and what problems you’re tackling at the moment. There are moments to lean into bold bets, and there are moments where restraint actually protects value. The skill is knowing which is which and then being intentional about it. I do truly believe that risk awareness is a leadership advantage, and I believe just as much that risk aversion can become a liability in the long run.

The third tip is around how we build a culture of confident decision-making and make decisions into a team sport. We do this by making ownership very clear but then inviting constructive friction into the process. I’m a big believer that every decision needs a single, accountable owner, but I don’t believe that ownership means isolation or individual empowerment to just go do something. The strongest outcomes come when that person draws on diverse perspectives from experts — and now I would include AI in the experts list that’s available to people — without collapsing into consensus. Constructive friction sharpens judgment. The art is in making it productive and retaining absolute clarity on who is accountable for the impact of that decision.

Ramakrishan’s perspective reminds us that successful leadership in this era won’t be defined by the amount of data or technology we have access to. Instead, it will be about the quality and speed of the decisions we make, and the trust and purpose behind them. For more valuable insights from her leadership playbook, tune in to the Tech Whisperers.

See also:

• CIO Jeanine Charlton’s leadership lessons in resilience
• Netskope CIO Mike Anderson on making the leap to a startup
• ‘Leaders grow leaders’: CIO Ken Piddington on developing IT talent

En un sector tan tradicional como el energético, altamente regulado y dominado históricamente por grandes eléctricas, la compañía Chippio ha emergido como un nuevo actor que viene a cambiar las reglas del juego. Se define como “la primera comercializadora de energía en España impulsada por inteligencia artificial” y basa todo su modelo en un enfoque digital que pretende devolver al usuario el mando de su consumo y su factura. Para ello, según su director general, Pol Brau, ofrece a los consumidores “herramientas para que tomen el control total de su factura de la luz, combinando tarifas a precio de coste con servicios innovadores y la que consideramos la app más avanzada del sector”.

A diferencia de la competencia, Chippio no se considera una comercializadora tradicional con añadidos digitales, sino una empresa tecnológica cuya propuesta de valor se basa en la transparencia y en el empoderamiento del consumidor. Para ello, su aplicación, que permite monitorizar en tiempo real los precios y el consumo, y su copiloto de IA, Emilia, se convierten en las piezas centrales de esa filosofía. “Somos la primera startup del sector en España en aprovechar plenamente la inteligencia artificial para empoderar al usuario”, explica Brau. Esto se materializa en servicios como Smart Charging, que optimiza automáticamente la carga del vehículo eléctrico, o el nuevo Guardián de Precios, un sistema pionero que combina la flexibilidad de la tarifa variable con la estabilidad de una tarifa fija, pero sin permanencia ni condiciones opacas.

La innovación como ADN corporativo

En Chippio, la innovación no es un área aislada, sino el motor de la compañía. “Nuestra estrategia de TI es clara: estamos centrados en el desarrollo de soluciones inteligentes que racionalicen el consumo energético y pongan la tecnología al servicio real del cliente. No innovamos por innovar; innovamos para devolver el control al usuario, mejorar radicalmente la experiencia de cliente y ofrecer herramientas que permitan un ahorro real y fomenten hábitos más sostenibles”, subraya Brau.

De acuerdo con el director general de la compañía, la práctica totalidad de la inversión se destina a TI. “Los ingresos que obtenemos de nuestro negocio se reinvierten íntegramente en seguir desarrollando servicios innovadores y digitales. Estamos en una fase de crecimiento, y contamos con el respaldo estratégico de nuestra matriz, Fortum, para acometer estas inversiones en tecnología”.

Toda la plataforma de Chippio se sustenta en IA y en un stack tecnológico basado en Microsoft Azure, además de integrar algoritmos propios para análisis de precios, envío de alertas y toma de decisiones automatizadas. La IA Emilia, que combina capacidades de ChatGPT con Azure AI, actúa como asistente y guía personalizada para los clientes. “Nuestra IA Emilia ha demostrado ser capaz de incrementar las tasas de conversión a cliente de pago entre un 250% y un 335%. Nos permite ofrecer un servicio altamente personalizado y de calidad con una plantilla ágil y digitalizada”, explica Brau.

Además, continúa el director general, “usamos algoritmos para el análisis de precios y el envío de alertas proactivas. En el caso de productos como Smart Charging, nuestra tecnología se basa en conexiones directas (APIs) con las aplicaciones de los propios fabricantes de vehículos eléctricos. Esto nos permite controlar la carga del vehículo de forma inteligente sin necesidad de que el cliente instale ningún hardware adicional”.

Nueva frontera de la estabilidad energética

Entre las innovaciones presentadas recientemente por la compañía destaca el Guardián de Precios, una herramienta “pionera en España”, según Brau, que “combina la flexibilidad de la tarifa variable (aprovechar los precios bajos) con la estabilidad y tranquilidad de una tarifa fija (protegerse de las subidas)”.

Para ello, el cliente recibe ofertas temporales con un precio fijo 24h competitivo y puede decidir, desde la app, si “congela” ese precio para su próximo ciclo de facturación completo con potencia a precio de mercado, eliminando márgenes opacos como los que establecen las compañías de luz en sus potencias. “Nosotros monitorizamos las tendencias futuras del mercado de la luz y sugerimos cuándo puede ser un buen momento para fijar el precio, permitiendo a los usuarios aprovechar una tarifa fija solo cuando les es más beneficioso”, explica Brau. De esta forma, se evita “que paguen de más estando demasiado tiempo en ellas, activándolo y desactivándolo desde la app sin permanencia”.

El servicio está totalmente integrado en la aplicación móvil, que es el canal a través del cual el usuario recibe la recomendación, y puede activar o desactivar la fijación del precio con total libertad.

El beneficio, según Brau, es doble: tranquilidad y control. “El usuario obtiene lo mejor de los dos mundos: la flexibilidad de la tarifa variable, para aprovechar los precios bajos, y la estabilidad de una tarifa fija cuando hay incertidumbre. Le permite asegurar una tarifa estable en periodos de mayor incertidumbre y volver al mercado variable cuando este resulta más favorable”.

IA al servicio del usuario y de la eficiencia del sector

La IA se ha convertido en una palanca clave para la innovación en el sector energético. Su capacidad para optimizar procesos, anticipar decisiones y personalizar servicios está redefiniendo el modelo operativo de las compañías. Según Brau, para las compañías como Chippio, la IA es “un motor de crecimiento y eficiencia”. Para los consumidores, “es la herramienta definitiva de empoderamiento”. Primero, porque “les permite entender un mercado que es tradicionalmente complejo y opaco. Segundo, les ofrece guías y consejos personalizados para el ahorro energético y para tomar decisiones más eficientes y sostenibles. Y tercero, automatiza decisiones complejas; por ejemplo, nuestro Smart Charging decide por ellos cuál es la hora más barata para cargar el coche, generándoles ahorros de hasta 600 euros anuales”.

Según el director general de Chippio, la irrupción de tecnologías disruptivas obligará al sector energético a pasar de modelos opacos y centrados en el activo a modelos digitales, transparentes y totalmente orientados al cliente. En este contexto,Chippio continuará reforzando su plataforma tecnológica para mantener un modelo de servicio diferencial en un mercado donde, según Brau, muchas compañías se centran en la captación y no en mejorar la experiencia real de sus clientes. “Queremos seguir ofreciendo una experiencia excelente en un sector donde rara vez se prioriza al usuario”.

2025년은 인수 합병이 활발한 한해였다. 로이터의 보도에 따르면, 골드만 삭스는 2025년 발표 기준 인수·합병 규모가 역사상 두 번째로 클 것이라고 전망했다.

네트워킹 분야에서는 2025년 성사된 대형 딜 상당수가 오래전부터 예고된 것이었다. 예를 들어, HPE가 주니퍼 네트웍스 인수를 최종 마무리하는 데만 18개월이 넘는 시간이 걸렸다. 팔로알토 네트웍스의 사이버아크(CyberArk) 인수처럼 250억 달러 규모의 큰 거래가 있는 반면, 규모는 작지만 영향력이 큰 인수합병도 있다. 여러 인수합병이 AI 역량을 중심에 두고 분산 자원 접근과 보안을 위한 더 강력한 시스템을 구축하려는 전략과 맞물려 있다.

엔터프라이즈 네트워킹의 미래를 좌우할 10여 건의 인수합병을 알파벳 순으로 정리했다.

아카마이, 퍼미온 인수

아카마이는 엣지 역량 강화를 목표로 웹어셈블리 스타트업 퍼미온(Fermyon)을 인수할 계획이라고 발표했다. 퍼미온은 웹어셈블리를 브라우저 영역에서 서버 사이드와 엣지 배포 영역으로 확장하는 데 기여했다. WASI(WebAssembly System Interface) 표준화가 임박하면서 이번 거래는 웹어셈블리 사용자 확대에 힘을 보탤 수 있다는 분석이 나온다.

아리스타, 벨로클라우드 인수

아리스타 네트웍스(Arista Networks)는 7월 브로드컴의 벨로클라우드(VeloCloud) SD-WAN 사업부를 인수했다. 인수 금액은 밝히지 않았다. 아리스타 입장에서 SD-WAN 기술을 인수해 부족했던 네트워킹 퍼즐 한 조각을 메우고, SD-WAN과 SASE, 지사 네트워킹 전략을 강화하는 계기가 됐다. 아리스타 CEO 제이슈리 울랄은 아리스타의 캠퍼스 및 광역 네트워크 사업 규모가 현재 7억 5,000만 달러에서 2026년 말까지 12억 5,000만 달러로 성장할 것이라고 전망했다.

AT&T, 루멘 광섬유 사업 인수

AT&T는 5월 루멘(Lumen)의 매스 마켓(Mass Market) 광섬유 사업 인수 계획을 발표했다. 57억 5,000만 달러 규모인 이번 거래는 통신사가 특히 인공지능 확산에 따른 트래픽 증가에 대응하면서 광섬유 기술을 얼마나 중시하는지를 보여준다. AT&T에 따르면, 루멘 매스 마켓 광섬유 자산에는 약 100만 명 광섬유 가입자와 400만 곳이 넘는 광섬유 서비스 제공 위치가 포함되어 있다.

시스코, 에즈더브스와 뉴럴패브릭 인수

시스코는 지난달 음성 간 통번역 기술을 보유한 비상장 AI 소프트웨어 업체 에즈더브스(EzDubs) 인수를 완료했다고 발표했다. 시스코는 자사 협업 솔루션에서 말투와 억양까지 보존하는 실시간 음성 번역 등 차세대 기능을 제공하는 데 에즈더브스의 기술을 활용할 계획이다. 11월에는 자체 데이터를 활용해 도메인 특화 SLM을 구축할 수 있는 생성형 AI 플랫폼을 제공하는 AI 플랫폼 기업 뉴럴패브릭(NeuralFabric)도 인수했다.

코어위브, 코어 사이언티픽 인수

엔비디아의 투자를 받은 AI 클라우드 서비스 업체 코어위브(CoreWeave)는 암호화폐 채굴 업체 코어 사이언티픽(Core Scientific)을 약 90억 달러에 인수했다. 코어위브는 이번 인수로 AI 및 고성능 컴퓨팅(HPC) 워크로드 수요 증가에 대응하기 위해 계약된 1.3기가와트 규모 전력을 확보하게 됐다고 밝혔다. 코어위브는 이번 거래로 직접 보유·운영하는 데이터센터 자산이 확대돼 수직 통합 구조가 강화되고, 엔터프라이즈 및 연구 기관 고객을 위한 GPU 기반 서비스 확장에 속도를 낼 수 있다고 설명했다.

F5, 칼립소AI, 플레치, 맨티스넷 인수

F5는 아일랜드 더블린에 본사를 둔 칼립소AI(CalypsoAI)를 1억 8,000만 달러에 인수했다. 칼립소AI의 플랫폼은 서로 다른 모델과 업체, 환경 전반을 보호하는 ‘추론 경계(Inference Perimeter)’를 구축하는 기능을 제공한다. F5는 칼립소AI의 적응형 AI 보안 역량을 자사의 애플리케이션 딜리버리 및 시큐리티 플랫폼(ADSP)에 통합할 계획이라고 밝혔다.

F5는 또 에이전틱 AI 및 위협 관리 스타트업 플레치(Fletch)를 인수해, 외부 위협 인텔리전스와 내부 로그를 실시간 우선순위 인사이트로 전환하는 플레치의 기술과 에이전틱 AI 기능을 ADSP에 더할 예정이다.

마지막으로 클라우드 네이티브 가시성 강화를 위해 스타트업 맨티스넷(MantisNet)을 인수했다. F5 블로그에 따르면, 맨티스넷은 eBPF 기반 커널 레벨 텔레메트리를 활용해 암호화 프로토콜 트래픽 활동에 대한 실시간 인사이트를 제공하고, 성능 저하 없이 가장 파악하기 어려운 트래픽까지 가시성을 확보하도록 지원한다.

HPE, 주니퍼 인수 마무리

7월에 최종 마무리된 134억 달러 규모의 이번 거래로 HPE의 네트워킹 사업 규모는 사실상 두 배가 됐고 AI 기술 역량도 대폭 강화됐다. 퓨처럼 그룹(Futurum Group)은 거래 종결 직후 발표한 보고서에서 이번 인수가 엔터프라이즈 캠퍼스, 데이터센터, 통신사업자, 클라우드 네트워킹을 아우르는 통합 포트폴리오를 구성하는 토대를 마련했다고 평가했다.

퓨처럼 그룹은 “이번 인수로 방화벽, 서비스 엣지, 제로 트러스트 아키텍처 전반을 아우르는 통합 네트워크 보안 제품을 제공할 수 있는 기회가 생겼다”라며, “통합 회사는 ‘네트워크를 위한 AI’와 ‘AI를 위한 네트워크’라는 두 시장 기회를 모두 공략하게 될 것”이라고 분석했다.

IBM, 하시코프 인수 최종 완료

IBM은 지난 2월 64억 달러에 인수한 하시코프(HashiCorp)를 전 세계 데이터센터에 자동화 및 보안 기술을 확산하는 데 활용할 것이라고 밝혔다. IBM은 하시코프의 자동화 기술을 레드햇, 왓슨엑스, 데이터 보안, IT 자동화, 컨설팅 사업 전반에 통합할 계획이다. 하시코프의 대표 제품에는 여러 클라우드와 온프레미스 환경에 걸쳐 인프라·네트워크·가상 컴포넌트를 프로비저닝할 수 있게 해주는 테라폼(Terraform) 패키지가 포함되어 있다.

넷기어, 엑시엄 인수

넷기어(Netgear)는 2025년 6월 SASE 포트폴리오 확대를 위해 비상장 보안 전문업체 엑시엄(Exium)을 인수했다. 소비자용 네트워킹 하드웨어로 잘 알려진 넷기어는 중견·중소기업을 위한 엔터프라이즈급 보안 솔루션으로 무게 중심으로 옮기고 있다. 넷기어 포 비즈니스(Netgear for Business) 부문 사장 겸 총괄 책임자인 프라모드 바드자테는 네트워크월드와의 인터뷰에서 “넷기어의 기반을 고려할 때, 중소·중견 기업 고객의 요구를 해결할 수 있는 넷기어만의 기회가 있다고 본다”라고 말했다. 또, “중소·중견 기업 고객은 대기업과 동일한 수준의 신뢰성을 원하면서도 그에 걸맞은 지원까지 기대하는 독특한 요구를 갖고 있다”라고 덧붙였다.

노키아, 인피네라 인수

노키아는 23억 달러 규모의 인피네라(Infinera) 인수를 통해 DWDM 기술 역량을 대폭 확대했고, 이를 기반으로 하이퍼스케일러 및 통신사업자급 솔루션을 강화할 계획이다.

팔로알토 네트웍스, 사이버아크 인수

팔로알토 네트웍스는 7월 250억 달러 규모의 사이버아크(CyberArk) 인수 계획을 발표해 네트워크 액세스 및 ID 관리 포트폴리오를 확장했다. 에베레스트 그룹(Everest Group)은 “팔로알토는 이번 인수를 머신·에이전트 ID 보호를 위한 궁극적인 도약의 기회로 삼고 있다. AI 기반 위협 시대에 가장 뜨거운 영역 중 하나다”라고 평가했다. 또, “이번 인수는 주요 사이버보안 업체가 AI 기반 엔터프라이즈의 필수 파트너로 자리매김하기 위해 어떤 방향으로 스스로를 재정의하려 하는지를 보여주는 지각 변동급 신호”라고 분석했다.

퀄컴, 알파웨이브 세미 인수

퀄컴은 데이터센터 네트워킹 및 컴퓨트 포트폴리오 확대를 위해 영국 하드웨어 제조사 알파웨이브 세미(Alphawave Semi)를 24억 달러에 인수했다. 알파웨이브 세미는 맞춤형 실리콘, 칩렛, ASIC, 반도체 지식재산(IP)을 포함해 다양한 유선 연결 및 컴퓨트 기술을 보유하고 있다. 퀄컴의 목표는 점점 더 고도화되는 AI 워크로드를 지원하기 위해 퀄컴 프로세서와 알파웨이브의 고속 연결·컴퓨트 기술을 결합하는 것이다. 무어 인사이츠 앤 스트래티지의 대표 애널리스트 맷 킴벌은 6월 인수 발표 당시 “퀄컴이 데이터센터 CPU 시장에 얼마나 진지하게 뛰어들고 있는지 보여주는 가장 강력한 증거가 바로 이번 인수”라고 평가했다.
dl-ciokorea@foundryco.com

자소설닷컴은 MZ세대가 기성세대보다 조직에 얽매이기보다 자율성을 더 중시한다는 인식이 있었지만, 실제 조사 결과는 이와 다른 양상을 보였다고 설명했다. 신입 구직자들은 막연한 자율성보다 체계적인 시스템 속에서 직무 전문성을 키우고, 안정적인 환경에서 성장하기를 원하는 경향이 더 뚜렷하게 나타났다는 것이다.

특히, 기업 문화에 대한 선호도에서 이러한 경향이 드러났다. ‘선호하는 기업 문화’를 묻는 질문에 전체 응답자의 89.8%가 ‘체계적이지만 다소 수직적인 대기업 문화’를 선택했다. 이와 대조적으로, ‘자율적이지만 모든 것을 스스로 책임져야 하는 스타트업 문화’를 선택한 비율은 10.2%에 그쳤다. MZ 취업준비생들은 조직의 자율성보다 안정된 구조와 시스템을 통해 성과를 달성하려는 의지가 강함하든 것이다.

자소설은 이러한 결과가 업무를 지도해 줄 선배와 명확한 매뉴얼이 갖춰진 환경을 성장에 유리하다고 판단한 것으로 분석했다. 검증된 시스템 속에서 불필요한 시행착오는 최소화하고 직무 전문성을 효과적으로 기르는 것을 실리적 선택으로 여기는 요즘 세대의 성향이 뚜렷하게 반영된 것으로 풀이된다.

성장 방식에 있어서도 ‘직무 전문성’에 대한 니즈가 뚜렷하게 드러났다. ‘더 선호하는 성장 환경’을 묻는 질문에 응답자의 과반인 59.0%가 ‘나의 직무만 깊게 파고들 수 있는 단일 직무 집중형’을 택했다. 과거 다양한 부서에서의 경험을 통해 제너럴리스트로 성장하는 것을 미덕으로 여겼던 것과는 확연히 대조적인 양상이다.

자소설은 이를 입사 초기부터 확실한 전문성을 길러 대체 불가능한 인재가 되고자 하는 요즘 세대의 태도가 반영된 것이라고 해석했다. 이러한 전문성 지향 성향은 최근 기업들의 채용 트렌드가 직무 중심으로 재편된 흐름과도 정확히 맞물린다고 덧붙였다.

이 배경에는 평생직장의 개념이 사라지고 있는 추세도 한몫했다. 직장인들의 이직이 보편화된 고용 환경 속에서, 구직자들은 개인의 직무 경쟁력과 전문성을 갖추는 것이 불확실한 미래에 생존할 수 있는 가장 확실한 전략이라고 판단한 것으로 보인다.

리멤버앤컴퍼니 자소설마케팅팀 이선정 팀장은 “이번 조사는 요즘 MZ세대 구직자들이 그들의 불확실한 미래를 대비하기 위해 가장 합리적이고 체계적인 방법을 찾는 ‘전략적 세대’임을 보여주었다”면서 “앞으로도 자소설닷컴은 신입 취준생들의 진정한 성장을 위해 체계적, 전략적으로 성공적인 커리어의 첫발을 내디딜 수 있도록 돕는 취업 성공 파트너가 될 것”이라고 밝혔다.
jihyun.lee@foundryco.com

AWS는 12월 초 미국 라스베이거스에서 열린 연례 컨퍼런스 리인벤트(re:Invent) 2025에서 클라우드 선두 기업으로서는 이례적으로 신중한 태도를 드러냈다. 엔터프라이즈 AI 분야에서 여전히 의제를 주도할 수 있음을 입증해야 한다는 압박이 행사 전반에 걸쳐 영향을 미친 것으로 보인다.

마이크로소프트(MS)와 구글이 통합형 AI 스택과 워크플로우 기반 에이전트 플랫폼을 앞세워 CIO들의 관심을 강화하는 가운데, AWS 최고경영자 매트 가먼과 주요 임원진은 신규 칩, 모델, 플랫폼 기능을 연이어 공개하며 CIO에게 가장 폭넓고 운영에 최적화된 AI 기반을 제공할 수 있다는 메시지를 강화하려 했다.

그러나 분석가들은 AWS가 이러한 목표를 달성했다고 보지 않는 분위기다.

딜로이트에서 최고 클라우드 전략 책임자로 활동했던 프리랜서 컨설턴트 데이비드 린시컴은 “전보다 가까워지긴 했지만, 아직 완성 단계에는 이르지 못했다”라고 말했다.

강력하지만 ‘완성형 솔루션’으로 보기엔 부족

새로운 기능과 서비스를 활용하기 위해 필요한 엔지니어링 작업은 AWS의 다른 발표에서도 반복됐다. 이로 인해 CIO들의 AI 로드맵을 단순화하기보다 오히려 혼란을 줄 수 있다는 우려가 제기됐다.

행사 이틀째, 스와미 시바수브라마니언은 베드록 에이전트코어(Bedrock AgentCore), 베드록(Bedrock), 세이지메이커 AI(SageMaker AI) 전반에 새로운 기능을 추가했다고 발표했다. 기업이 에이전트형 AI 파일럿을 운영 환경으로 확장하도록 지원하겠다는 취지였지만, 린시컴은 기본적으로 개발자의 작업을 가속하는 도구 제공에 초점이 맞춰져 있을 뿐, 여전히 ‘플러그 앤 플레이형 에이전트’를 기본 제공하는 방식과는 거리가 있다고 지적했다.

더큐브 리서치의 수석 애널리스트 폴 내셔워티 역시 바이브 코딩 도구 키로(Kiro) 업데이트나 데브옵스 단순화를 위해 도입된 신규 개발자 중심 에이전트에서도 같은 문제가 반복됐다고 설명했다. 내셔워티는 “AWS는 MS의 코파일럿 스튜디오와 구글 제미나이 에이전트를 정면에서 겨냥하고 있으며, 기능 격차는 줄어들고 있다”라고 말했다. 이어 “하지만 여전히 엔지니어링 부담이 존재한다. MS와 구글은 생산성 도구와의 통합이 더 촘촘하다. AWS도 따라잡고 있지만, 애플리케이션 환경에 따라 팀이 구현 작업에 더 많은 시간을 투입해야 할 수 있다”라고 전했다.

통합된 AI 플랫폼 전략을 제공하는 측면에서도 AWS는 큰 진전을 보여주지 못했다. 분석가들은 AWS가 복잡한 단편화를 해소하기 위해 보다 명확한 ML옵스 경로, 베드록과 세이지메이커 간의 깊은 통합, 모델 구축에서 실제 에이전트 대규모 배포로 이어지는 ‘준비된 패턴’을 제시할 것으로 기대했다.

그러나 린시컴은 베드록·세이지메이커·데이터플레인 간 연결 구조를 AWS가 충분히 문서화하거나 지원하지 못했다고 평가했다. 그는 “여전히 핵심 서비스들이 충분히 통합돼 있지 않다”라며 “거의 모든 작업에 서로 다른 접근법이 남아 있어 일관된 흐름을 만들기 어렵다”라고 지적했다.

린시컴은 AWS의 접근 방식이 MS와 구글의 전략과는 극명하게 대비된다고도 언급했다. MS는 패브릭(Fabric)을 중심으로, 구글은 데이터와 버텍스 AI 스택을 기반으로 보다 일관된 엔드 투 엔드 스토리를 제시하고 있다는 것이다.

만들 것인가 살 것인가

AWS의 발표 내용을 확인한 뒤 엔터프라이즈 AI 로드맵을 확정하려던 CIO들은 다시 익숙한 갈림길 앞에 서게 됐다. 강력한 기반 도구를 선택할 것인지, 아니면 즉시 사용할 수 있는 완성형 플랫폼을 선택할 것인지다.

가트너 부사장 애널리스트 짐 헤어는 CIO들이 AWS가 새롭게 추가한 모듈형 스택을 충분히 활용하려면 아키텍처 운영 원칙, ML옵스 성숙도, 데이터 거버넌스 기반을 스스로 갖추고 있는지 평가해야 한다고 설명했다.

헤어는 “장기적인 통제력과 맞춤화를 중시하는 CIO에게 AWS는 비교할 수 없는 유연성을 제공한다. 반면 속도와 단순성, 매끄러운 통합을 우선한다면 2026년에도 MS나 구글이 더 실용적인 선택지가 될 수 있다”라고 말했다.

결국 선택의 본질은 언제나 그렇듯, 기업이 AI 플랫폼을 직접 구축할 것인지, 아니면 사서 사용할 것인지에 달려 있다.
dl-ciokorea@foundryco.com

그래픽 패키징 인터내셔널(GPI)의 CIO 비쉬 나렌드라는 오랜 기간에 걸쳐 기술팀을 단순히 솔루션을 구현하는 조직이 아니라 실질적인 비즈니스 문제를 해결하는 조직으로 재편해 왔다. 이런 접근은 가시적 성과를 이끌어냈을 뿐 아니라, 그의 이사회 활동 기반을 다지는 데도 중요한 역할을 했다. 나렌드라는 부서 간 신뢰 구축과 전략적 네트워킹에 초점을 둔 5년간의 체계적인 이사회 진출 계획을 통해, 기술 임원이라도 비즈니스 리더십을 갖추면 이사회와 같은 거버넌스 역할로 자연스럽게 활동 범위를 넓힐 수 있음을 보여줬다.

비상장 대기업 이사회에 참여하고 있다. 그 자리에 어떻게 오르게 됐나?

커리어 초창기부터 쌓아온 모든 경험이 결국 이사회 역할로 이어졌다. 이 목표를 매우 의도적으로 추구했다. 약 5년 전, 운영 책임자 이상의 진로를 고민하기 시작했고, 그 과정에서 컨설팅, 자문, 이사회 활동 등이 후보로 떠올랐다. 아무것도 하지 않는 것은 고려 대상이 아니었다.

당시 많은 이사회가 사이버보안과 트랜스포메이션 전략을 논의하고 있었고, CEO나 CFO 중심의 기존 이사회를 보완할 CIO의 목소리가 필요했다. 이러한 기회를 보고 이사회 진출을 위한 준비를 시작했다.

먼저 신뢰하는 사람들에게 조언을 구했다. 그들은 포지셔닝을 정리하고 이력서를 만드는 데 큰 도움을 줬다. 조언에 따르면 운영 책임자와 이사회 멤버는 성격이 크게 달랐다. 특히 이사회에서는 기존에 사용하던 기술 및 사이버 보안 용어를 쓰기 어려웠기에 주의가 필요했다. 이 외에 판매, 조달, 품질 등 다양한 분야에서 쌓은 직무 경험과 현재 GPI에서 대금 지급, 수금, 급여, 출장경비 처리 등 글로벌 비즈니스 서비스를 책임지고 있다는 점을 강조하라는 조언이 있었다.

이는 이사회 구성원 모두가 인재 개발, 시장 전략, 고객 서비스, 운영 등 고유한 전문성을 갖고 있다는 점을 보여준다. 기술 경험은 이사회에 들어설 수 있는 ‘입장권’일 뿐이며, 그 이상의 영역에도 기여해야 한다는 것이 핵심이었다.

스스로를 어떻게 포지셔닝했으며, 이사회 진출 준비는 어떻게 시작했나?

제조 및 공급망, 소프트웨어 개발, 손익(P&L) 책임을 맡아온 경력을 돌아보면서, 디지털 트랜스포메이션과 공급망 최적화를 필요로 하는 곳이 전문 분야라고 판단했다. 그래서 스스로를 시장 진출 및 트랜스포메이션을 주도하는 리더로 포지셔닝했다.

이사회 진출 준비를 본격적으로 시작하기 전에 먼저 CEO의 승인을 받았고, CFO와 CHRO에게도 계획을 공유했다. 그 후 네트워킹을 시작했다. 이사회 의석의 70%가 기존 이사회 구성원의 추천 네트워크를 통해 채워진다는 사실을 알고 있었기 때문에, 이사회에 있거나 이사회를 자문하는 인물들을 전부 목록화했다. 여기에는 주요 회계법인과 보상 컨설턴트도 포함됐다.

이후 분기마다 네다섯 명에게 연락해 관심 분야와 이력서를 공유했으며, 상장 기업과 비상장 기업의 이사회 모두에 관심이 있다고 밝혔다.

현재 비상장 기업의 이사회에서 활동하고 있다. 어떤 기여를 하고 있나?

감사위원회와 인사·거버넌스위원회에서 활동하고 있다. 여기에는 신규 이사 후보를 찾기 위해 인맥을 활용하는 일도 포함된다. 지금의 회사는 재고 회전율이 핵심인 유통 기업이다. B2B 기업에서 전자상거래 기반의 매출 확대를 지원한 경험을 이사회 활동에도 활용하고 있다.

하지만 그보다 더 중요한 기여는 기술 전문성과 비즈니스 리더십을 결합한 관점을 제시하는 데 있다. GPI의 CIO로서 스스로를 비즈니스 리더로 인식해 왔다. 회사의 비전과 운영 계획을 출발점으로 삼아, 조직의 자원을 비즈니스 영향력 창출에 집중한다. 예를 들어, 공장별로 분산돼 있던 기술 조달을 중앙화해 구매력을 높였고, 이를 통해 운영비를 절감했다. 지금은 에이전틱 AI를 활용해 더 빠른 속도와 비용 절감을 실현하고 있다. 이는 단순한 기술 구현이 아니라 비즈니스 리더십의 결과다.

비즈니스 리더십을 조직 문화에 어떻게 뿌리내리고 있나?

기술 기반의 산업 기업을 성장시키는 힘은 최고 수준의 개발자를 채용하는 데서 나오지 않는다. 현장을 직접 방문하고, 고객 서비스팀 옆에 앉아 실제 업무 경험을 이해하는 기술팀에서 나온다. 기자가 최전선의 소식을 알기 위해 군대와 함께 움직이듯, 기술팀을 운영 조직 안에 배치해 실제 문제를 해결하도록 한다. 직속 직원들은 이해관계자 회의가 있으면 내 회의는 건너뛴다.

시니어 리더들은 기술적 깊이를 갖춰야 하지만, 그 과정에서 비즈니스 도메인 지식도 함께 쌓게 된다. 예를 들어, SAP 팀 리더는 SAP 기술보다 제조 공정에 대한 지식을 더 많이 활용한다. 그는 현장의 모든 자산과 그 자산이 제품을 어떻게 만드는지 알고 있으며, 이를 시스템에도 반영할 수 있다. SAP를 어떻게 구현하느냐가 아니라 ‘골판지 상자를 어떻게 생산할 것인가’를 먼저 떠올리는 사람이 더 큰 가치를 만든다는 뜻이다.

팀의 한 기술 리더는 탁월한 직원 관리 역량과 강한 실행력을 갖추고 있었고 성장 의지도 컸지만, GPI에서 리더십을 발휘하려면 비즈니스 지식이 필수이기 때문에 역량만으로는 한계가 있었다. 그래서 그를 애플리케이션 분야로 이동시켰다. 단기적으로는 도전적 선택이었지만, 비즈니스 지식을 개발하기 위한 전략적 배치였다. IT 조직의 비즈니스 리더십을 강화하려면 구성원을 익숙한 영역에서 꺼내 실제 비즈니스가 어떻게 돌아가는지 더 깊이 배우게 해야 한다.

팀이 ‘비즈니스’라고 말하면 이를 재무, 운영, 판매 등으로 구체화하도록 한다. 의사소통을 위해 이런 구분이 필요하지만, IT와 비즈니스를 분리된 영역으로 볼 수는 없다. 서로 다른 기능일 뿐, 한 조직 안에서 함께 움직이는 역할이다.

GPI에서 공유 서비스를 새로 맡았을 때, 합류한 팀은 왜 CIO 조직에 속해야 하는지 이해하지 못했다. 그들의 언어를 이해하고 소통할 수 있다는 점을 증명해야 했다. 단순히 코딩만 하는 기술자가 어느 날 갑자기 상사로 등장한 것이 아니라는 점을 보여줘야 했던 것이다. 그래서 부서명도 정보 기술(IT)에서 ‘트랜스포메이션 및 기술’로 바꿨다.

연말 은퇴 후 이사회 활동에 더 집중할 계획이라고 밝혔다. 최근 AI 도입이 확산되는 흐름을 어떻게 보고 있나?

일부 이사회에서는 CEO 직속으로 AI 리더를 영입하는 방안이 논의되고 있다. 하지만 기업의 전환을 이끄는 역할은 CIO가 맡아야 한다고 본다. CIO와 기술 조직은 회사의 기반 시스템을 운영하며, 그 과정에서 모든 업무 흐름을 가장 넓고 깊게 이해한다. CIO가 전사적 전환을 이끌고 있다면, AI는 그 전환을 뒷받침하는 여러 기술 가운데 하나로 자리 잡아야 한다. 물론 AI는 파괴적 기술이지만, 그렇기 때문에 CIO가 이끌어야 한다고 생각한다.

만약 그렇지 않으면 CIO 조직이 AI 리더 산하로 들어가 두 조직의 역할이 뒤섞이거나 단절될 위험이 생긴다. 또한 기존 조직과 충분한 관계와 비즈니스 맥락을 갖추지 못한 AI 리더가 합류해 내부에서 ‘거부 반응’을 일으킬 수 있다. 연구 개발(R&D) 조직 수준에서는 별도의 AI 리더가 의미 있을 수 있지만, 기업 환경에서는 전체 디지털 전략과 운영 맥락을 가장 깊이 이해하는 CIO가 AI 리더십을 맡는 것이 더 적합하다고 본다.
dl-ciokorea@foundryco.com

AI 프로젝트 상당수가 실패한다는 연구 결과가 이어지고 있으며, 그 실패 비율이 최대 95%에 달한다는 분석도 있다. 그러나 많은 전문가는 문제의 원인이 모델이 아니라, 파편화돼 있거나 불충분하거나 품질이 낮은 데이터에 있다고 지적한다.

세일즈포스는 이러한 문제를 해결하기 위해 최근 인수한 인포매티카(Informatica)를 통합하기로 했다. 클라우드 데이터 관리 기업인 인포매티카의 지능형 데이터 관리 클라우드(IDMC)는 세일즈포스의 에이전트포스 360, 데이터 360, 뮬소프트 플랫폼에 연동될 예정이다.

기술 분석 기업 밸루아(Valoir)의 최고경영자 레베카 웨테만은 이번 통합이 CRM 중심의 세일즈포스에게 “매우 결정적인 전환점”이라고 평가했다. 그는 “이번 통합은 세일즈포스가 가진 데이터 영역을 확실히 강화하는 조치다. 인포매티카가 제공하는 핵심 가치는 풍부한 메타데이터 계층이며, 이를 통해 에이전트포스가 CRM 데이터에만 제한된 것이 아니라는 시장 신뢰도도 확보하게 된다”라고 설명했다.

전사 데이터 맥락 제공이 목표

세일즈포스의 신규 통합 AI 플랫폼인 에이전트포스 360은 사람, AI 에이전트, 애플리케이션, 데이터를 하나로 연결해 이른바 ‘360도 뷰’를 제공하도록 설계됐다. 이 기반 역할을 수행하는 것이 데이터 360(구 데이터 클라우드)이다.

이제 에이전트포스 360에 인포매티카가 추가되면서, 세일즈포스가 추구하는 목표는 기업의 핵심 비즈니스 데이터와 그 복잡한 연관성을 에이전트가 이해하도록 지원하는 ‘엔터프라이즈 차원의 이해’ 체계를 구축하는 데 있다.

세일즈포스에서 통합 데이터 서비스·데이터 360·AI 기반을 총괄하는 라훌 오라드카르 부사장은 간담회에서 “세일즈포스의 메타데이터 모델과 카탈로그를 인포매티카의 엔터프라이즈 전사(全社) 카탈로그와 결합해 완전한 데이터 인덱스를 구축하고 있다”라고 설명했다.

그는 인포매티카 기반의 엔터프라이즈 마스터 데이터 관리(Master Data Management, MDM)가 자산, 제품, 공급업체 등 여러 영역에 걸쳐 일관된 ‘골든 레코드’를 제공한다고 전했다. 이를 통해 에이전트는 온프레미스든 데이터 레이크든 다양한 시스템에 흩어진 자산 지도를 확인할 수 있게 된다. 데이터 계보(lineage) 기능은 데이터가 생성돼 수집되기까지의 여정을 추적하며, ‘제로 카피’ 기능은 데이터를 이동하지 않고 사용할 수 있어 스토리지 비용을 낮춘다.

간담회에서 인포매티카 최고제품책임자 크리시 비탈데바라는 인포매티카의 IDMC(Intelligent Data Management Cloud)가 데이터 전체 흐름을 발견하고 정제하고 보호하고 통합함으로써 “추측을 대체한다”라고 설명했다. 이는 인포매티카의 미션인 ‘경계를 없앤 데이터(data without boundaries)’를 구현하는 방식이라고 말했다. 그는 “IDMC는 기업 전체를 구동시키는 관리된 발전소와 같다”라며 “우리는 데이터의 스위스가 될 것이고 AI의 스위스가 될 것”이라고 표현했다.

이를 보완하기 위해 세일즈포스의 뮬소프트는 재고 변화, 배송 지연 등 실제 운영 데이터를 제공한다. 오라드카르는 이러한 실시간 작업 메모리가 중요하다며 “에이전트는 지금 무슨 일이 일어나고 있는지 알아야 한다”라고 말했다.

에이전트포스 360은 네 가지 층위로 구성된다. 첫 번째 층위는 데이터 360, 인포매티카, 뮬소프트가 결합해 맥락을 제공하는 구조이고, 두 번째 층위는 세일즈포스가 지난 20년간 축적한 영업·서비스·마케팅·커머스 관련 비즈니스 로직과 워크플로우다. 세 번째 층위는 기업이 캠페인 에이전트나 공급망 에이전트 같은 특화 에이전트를 구축·관리·오케스트레이션하는 ‘커맨드 센터’이며, 네 번째 층위는 실제로 에이전트를 배포하는 실행 영역이다.

오라드카르는 플랫폼이 개방성과 확장성을 전제로 구축돼 기업이 세일즈포스 생태계에만 얽매일 필요가 없다고 설명했다. 기업은 오픈AI, 아마존웹서비스(AWS), 마이크로소프트(MS) 애저, 구글 클라우드 플랫폼(GCP), 오라클, 하이브리드 환경 등에서 만들어진 써드파티 에이전트를 자유롭게 활용할 수 있다.

AI는 ‘어리석을’ 수 있다

인포매티카의 크리시 비탈데바라는 데이터의 품질, 일관성, 그리고 맥락이 가치를 좌우하는 핵심 요소라고 강조했다. 그는 서로 다른 시스템이 고유한 언어·규칙·정의를 갖고 있기 때문에, 데이터가 흩어져 있거나 오래됐거나 일관성이 없을 경우 AI는 전체 그림을 제대로 파악할 수 없다고 설명했다.

비탈데바라는 “데이터만으로는 충분하지 않다는 사실은 모두 알고 있다. 에이전트 기반 AI와 에이전트형 엔터프라이즈 시대에는 맥락이 새로운 화폐다”라며, 데이터 계보와 관계성, 거버넌스가 제품의 의미, 프로세스의 작동 방식, 데이터의 출처와 신뢰성을 AI에 알려주는 요소라고 말했다. 그는 “맥락은 AI의 작업 메모리이자 상황 인식의 디지털 버전과 같다”라고 설명했다.

세일즈포스의 라훌 오라드카르도 현재 AI 에이전트가 ‘단편’만을 보기 때문에 공유된 이해가 없으면 결국 추측할 수밖에 없다고 지적했다. 그는 “모델은 놀라울 만큼 지능적이지만 동시에 어리석다. 세상에 대해서는 거의 모든 것을 알고 있지만, 기업의 비즈니스에 대해서는 아주 조금만 알고 있다”라고 말했다.

하지만 모든 시스템과 워크플로우, 에이전트가 동일한 맥락 안에서 작동하면 의사결정 속도는 크게 빨라질 수 있다. 비탈데바라는 “AI는 훨씬 더 정확해지고 자동화는 더욱 신뢰할 수 있게 된다”라고 전했다.

CRM 데이터를 넘어

밸루아의 레베카 웨테만은 영업·마케팅·고객 서비스 등 특정 목적의 특화 AI 에이전트든, 보다 광범위한 상황을 다루는 범용 에이전트든, 기업이 CRM 데이터만으로는 충분하지 않다고 강조했다. 그는 AI가 ‘합리적인 수준의 정확도’에 도달하려면 데이터가 맥락 안에 놓여 있어야 하며, 실제 작동하는 “진짜 메타데이터 패브릭”이 이를 뒷받침해야 한다고 설명했다.

웨테만은 또 인포매티카가 제공하는 데이터 계보가 “학습 곡선과 기술 부담을 모두 낮춰준다”라고 말했다.

여기에 AI 에이전트에 대한 기업의 전반적 인식은 ‘뒤처지지 않기 위한 두려움’ 즉 FOMO(fear of missing out)에서 FOMU(fear of messing up) 다시 말해 ‘잘못될까 두려운 공포’로 이동했다고 웨테만은 분석했다. 기업들이 걱정하는 핵심은 ERP 데이터를 에이전트에 연결하는 과정에서 “A) 올바른 데이터인지, B) 데이터가 너무 많지는 않은지, C) 인프라팀에 과도한 부담을 주지 않는지, 그리고 마지막으로 가장 중요한 점일 수도 있는 D) 비용이 과도하게 발생하지 않는지”라는 것이다.

실제로 가격은 기업의 최우선 관심사다. 세일즈포스가 AI 에이전트 플랫폼 가격 인상을 논의하고, 새로운 AI 계약을 ‘수익화’하며, 다시 좌석 기반 및 사용량 기반 모델을 검토하고 있기 때문이다. 웨테만은 “기업이 주목하는 것은 가격 그 자체뿐 아니라, 가격 구조의 투명성과 예측 가능성”이라고 설명했다.

인포매티카 고객들이 이번 통합의 영향을 우려하는 것과 관련해, 웨테만은 세일즈포스가 태블로 인수 당시 명확한 로드맵과 지원 체계를 제공했던 선례를 언급하며 “세일즈포스가 태블로와 태블로 고객을 통합한 방식에 비춰보면, 인포매티카 고객은 걱정할 필요가 없다”라고 전했다.

다만 이번 간담회에서 세일즈포스와 인포매티카는 통합 플랫폼의 라이선스나 가격, 기존 인포매티카 고객을 어떻게 지원할지에 대한 구체적 내용을 공개하지 않았다.
dl-ciokorea@foundryco.com

앤트로픽, 아마존웹서비스(AWS), 구글, 마이크로소프트(MS), IBM, 오픈AI 등 주요 기술 기업이 AI 에이전트의 공통 표준을 마련하기 위해 협력한다. 이는 CIO에게 더 넓은 선택지를 제공하는 동시에, 특정 벤더 플랫폼에 대한 의존도를 낮추는 계기가 될 전망이다.

지난 9일 출범한 에이전틱 AI 재단(Agentic AI Foundation, AAIF)은 에이전트가 데이터에 접근하고 비즈니스 시스템과 상호작용하는 공통 프로토콜을 개발하는 것을 목표로 한다. 독점 도구에 의존하는 시장 구조가 에이전틱 AI의 폭넓은 도입을 제한할 수 있다는 우려가 커지고 있기 때문이다.

초기 에이전틱 AI 도입 사례 중 상당수는 맞춤형 커넥터나 특정 벤더의 프레임워크에 의존하고 있어, 프로젝트가 확장되면 다른 도구를 통합하기 어렵다는 문제가 발생한다. 최근 퓨처럼 그룹 보고서는 에이전트 기반 환경이 파편화되고 일관성이 부족하다고 지적하며, 개방형 사양이 없다면 향후 기업의 비용과 거버넌스 리스크가 커질 수 있다고 경고했다.

AAIF의 목표는 에이전트가 인증을 수행하고, 맥락을 공유하며, 여러 시스템을 가로지르며 작업을 실행하는 방식을 합의해 에이전트 간 협업을 더 쉽게 만드는 데 있다.

앤트로픽은 이미 업계에서 채택되고 있는 MCP(Model Context Protocol)를 AAIF의 핵심 출발점으로 제공했다. 여기에 블록(Block)의 구스(goose)와 오픈AI의 AGENTS.md도 초기 프로젝트 세트에 포함되면서, 재단은 완전히 새 표준을 만드는 대신 이미 자리 잡은 구성요소 위에서 활동을 시작할 수 있게 됐다.

증가하는 리스크가 표준화를 주도

최근 기업은 에이전틱 AI를 실험하는 과정에서 예상치 못한 종속과 통합 복잡성에 부딪히며 아키텍처 리스크를 노출하고 있다. 분석가들은 그 근본적인 문제로, 에이전트가 특정 플랫폼 환경에 맞춰 학습한 작업 방식이 보이지 않는 종속성을 만들어낼 수 있다는 점을 지적한다.

그레이하운드 리서치 최고 애널리스트 산치트 비르 고기아는 “에이전틱 플랫폼에서는 종속성이 시스템 구조가 아니라 에이전트가 일하는 방식에 녹아들어 있다. 겉으로는 모듈형처럼 보이지만, 실제로 기업이 다른 플랫폼으로 옮기거나 기술을 다양화하려 하면 예상보다 훨씬 복잡하게 얽혀 있는 경우가 많다”라고 말했다.

카덴스 인터내셔널의 수석 부사장인 툴리카 실도 같은 견해를 보였다. 실은 기업이 에이전틱 AI를 도입할 경우 특정 벤더의 독점 프로토콜과 인프라에 묶일 위험이 크고, 그 결과 유연성이 떨어지며 전환 비용도 높아진다고 설명했다. 그는 AAIF 출범이 “기업이 에이전틱 AI를 보다 신뢰할 만한 방식으로 도입하게 하며, AI 선택에 대한 통제력을 높일 수 있도록 돕는다”라고 분석했다.

공통 표준이 아키텍처를 바꾸는 방식

핵심은 여러 벤더가 실제 운영 환경에서 쓸 수 있는 인터페이스와 안전 규칙에 합의할 수 있느냐다. 분석가들은 이 합의가 이루어지느냐에 따라 AAIF가 기업용 에이전트 도입의 핵심 기반으로 자리 잡을지, 아니면 영향이 제한적인 또 하나의 표준화 시도로 남게 될지가 결정될 것이라고 보고 있다.

IDC 리서치 부사장 샤라스 스리니바사무르티는 “현재 생성형 AI 사용례의 약 70%가 오픈 파운데이션 모델을 기반으로 하고 있으며, 기업의 80% 이상이 생성형 AI 애플리케이션 스택에서 오픈소스를 매우 중요하게 평가하고 있다. 특히 개발과 미세 조정 단계에서 이런 경향이 두드러진다. 결과적으로 기업은 이미 개방형 환경을 전제로 아키텍처를 설계하고 있다”라고 말했다.

공통 프로토콜은 이런 변화에 속도를 더할 수 있다. 옴디아(Omdia) 최고 애널리스트 리안 지에 수는 에이전트 상호운용성을 위한 공통 표준이 AI 아키텍처의 설계와 배포 방식을 근본적으로 재편할 가능성이 있다고 분석했다.

수는 “먼저 에이전틱 AI 애플리케이션이 특정 벤더의 폐쇄적 구조에서 벗어나 플러그앤플레이가 가능한 모듈형·조합형 시스템으로 전환될 가능성이 있다. 또한 기업은 특정 환경에 얽매이지 않고 워크로드를 여러 환경 간에 쉽게 이동할 수 있는 이식성을 확보하게 된다”라고 설명했다.

수는 명확한 표준이 거버넌스와 오케스트레이션 수준까지 개선할 수 있다고 덧붙였다. 투명한 감독 체계와 일관된 통합 규칙이 마련되면, 기업이 다중 에이전트 워크플로우를 더 효율적으로 조율할 수 있다는 설명이다. 그는 “정확하고 신뢰할 수 있는 결과를 대규모로 만들어내기 위해서는 이러한 매끄러운 오케스트레이션이 필수”라고 말했다.

벤더 연합의 미래는?

표준화 논의가 탄력을 받고 있지만, 분석가들은 실제 구현이 시작되면 벤더 간 협력을 유지하는 일이 더 어려울 수 있다고 지적했다.

고기아는 AAIF의 실제 과제가 기술이 아니라 실행 과정에서 드러나는 행동적 측면에 있을 것이라고 진단했다. 그는 많은 벤더가 문서 단계에서는 쉽게 합의하더라도 실제 운영에서는 흔들리는 경우가 잦다고 설명했다. 특히 에이전틱 AI 시스템의 복잡성이 이러한 문제를 더욱 키운다고 그는 분석했다.

고기아는 “에이전틱 AI는 단순한 인프라가 아니다. 소프트웨어에 자율적 의사결정이 그대로 코드화된 구조다. 에이전트가 예상과 다르게 움직이거나, 표준과 구현이 어긋나면 문제는 단순한 시스템 버그에 그치지 않는다. 법적 리스크, 운영 장애, 평판 훼손까지 이어질 수 있다”라고 설명했다.

수도 협력이 가능하다는 점에는 동의했지만, 보장되지는 않는다고 평가했다. 그는 “주요 벤더가 에이전트 거버넌스, API, 안전 프로토콜에 공통으로 합의하는 것은 현실적으로 가능하지만 매우 도전적인 일”이라며, 높아지는 기대치와 규제 압력을 난제로 꼽았다.

실은 향후 진전을 가늠할 수 있는 초기 지표로 MCP와 AGENTS.md의 실제 운영 환경 확대, 벤더 간 공동 거버넌스 지침, 그리고 여러 플랫폼에서 일관되게 동작하는 감사 및 에이전트 간 통신 도구를 꼽았다. 그는 “기업이 이런 도구와 안전 체계를 개념 증명(PoC) 수준이 아니라 대규모 운영 환경에서 활용할 수 있을 때, 비로소 표준이 제대로 작동하고 있다고 볼 수 있을 것”이라고 말했다.
dl-ciokorea@foundryco.com

AI 확산과 함께 인프라 전환의 필요성이 커지고 있지만, 여전히 많은 기업들이 실행에 어려움을 겪고 있는 것으로 나타났다. 전체 응답자의 84.7%는 ‘클라우드 네이티브 전환이 필요하다’고 답했으며, 그중 절반 이상은 ‘매우 필요하다’고 응답했다. 전환 필요성에 대한 인식이 확산되면서, 실제 준비 현황에 대한 관심도 높아지고 있다.

그러나 전환 수준은 여전히 초기 단계에 머물러 있다. 전환을 완료했거나 절반 이상 진행 중이라고 응답한 비율은 18.4%에 불과했다. 대부분 초기 논의 단계(39.5%)에 머물러 있거나, 일부 업무에만 시범 적용(27.6%)하는 데 그쳤다. 전환에 대한 공감대는 형성됐지만, 실행으로 이어지지 못하는 현실적 한계도 뚜렷했다.

기업들이 전환 과정에서 가장 많이 겪는 어려움은 ‘운영 복잡성’이었다. 운영 복잡성 증가(18.3%)와 기존 시스템의 복잡성(17.4%)이 주요 제약 요인으로 꼽혔고, 전문 인력 부족(16.9%)과 보안‧규제 부담(10.5%)이 뒤를 이었다.

복잡해진 클라우드 환경도 전환 필요성을 높이는 배경으로 지목됐다. 응답자의 82.9%는 ‘멀티 및 하이브리드 환경의 운영 복잡성’이 클라우드 네이티브 전환 필요성에 영향을 미친다고 답했다. 클라우드 환경을 안정적으로 운영하기 위해 구조적인 전환이 필요하다는 인식이 확산되고 있다.

클라우드 네이티브 전환을 통해 기대하는 효과도 분명했다. 기업은 인프라 운영 자동화 향상(24.9%), AI 서비스 대응 속도 향상(19.7%), DR·복구력 강화(16.8%) 등을 기대했다. 이 밖에도 신규 서비스 출시·배포 속도 향상(15.6%), 비용 효율성 제고(15.6%) 등 다양한 기대가 고르게 나타났다.

클라우드 네이티브 전환 논의가 확산되면서 운영 안정성과 서비스 연속성 확보가 기업의 핵심 과제로 부상하고 있다. 오케스트로는 이에 대응해 전환부터 AI 인프라 최적화, 재해복구(DR) 전략까지 아우르는 ‘풀스택 소버린 AI 클라우드 아키텍처’를 기반으로 전환과 운영 안정성을 동시에 지원한다고 밝혔다.

오케스트로는 KT클라우드와 공동 투자한 대구 민관협력형(PPP) 클라우드 존 운영 경험을 바탕으로 컨설팅부터 설계, 구축, 운영까지 전환의 전 과정을 직접 수행하고 있다고 설명했다. 자체 개발한 MSA 분석 자동화 툴은 기존 시스템 분석 시간을 기존 대비 약 1/10로 단축해, 복잡한 환경에서도 신속하고 체계적인 전환을 가능하게 한다는 설명이다.

또한 AI 인프라 운영 효율화를 위해, 오케스트로는 서버 가상화 솔루션 ‘콘트라베이스(CONTRABASS)’와 클라우드 네이티브 운영관리 플랫폼 ‘비올라(VIOLA)’를 기반으로 GPU 가상화(GPUaaS)와 노드‧리소스 통합 관리를 구현한다. 아울러 오케스트로는 최근 DR 전문 기업 인수를 통해 CDP(연속 데이터 보호) 기술을 포함한 DR 전 영역의 핵심 역량을 내재화하고 고도화해 왔다고 설명했다.

오케스트로 김범재 대표는 “많은 기업들이 클라우드 네이티브 전환의 필요성은 인식하고 있지만, 복잡한 환경과 기술적 제약으로 실행에 어려움을 겪고 있다. 오케스트로는 고객의 안정적인 클라우드 네이티브 전환과 운영 효율성뿐만 아니라 서비스 연속성까지 확보할 수 있도록 적극 지원하겠다”라고 말했다.
dl-ciokorea@foundryco.com

MIT의 11월 보고서에 따르면, 전체 기업의 35%는 이미 에이전틱 AI를 도입했고 44%는 곧 도입할 계획이라고 답했다.

MIT는 보스턴 컨설팅 그룹과 함께 2,000명 이상을 대상으로 설문조사를 진행했고, 자율형 에이전트를 배포하기 전에 중앙집중식 거버넌스 인프라를 구축하라고 권고했다. 하지만 기업이 생존 경쟁을 벌이고 있다고 느끼는 상황에서는 거버넌스가 뒷전으로 밀리기 쉽다. 금융 서비스 같은 규제 산업은 예외에 속한다.

익스피리언(Experian)의 글로벌 그룹 CTO 로드리고 로드리게스는 “익스피리언은 여러 해 동안 AI 혁신을 이어왔다”라며, “금융 서비스 분야에서 AI 활용은 이해관계가 매우 크다. 규제, 윤리, 성능 기준이 개발부터 배포까지 전 과정에 녹아 있는지 모든 AI 사용례마다 꼼꼼히 검증해야 한다”라고 설명했다.

로드리게스는 모든 모델을 지속적으로 테스트하고, 보유한 에이전트 목록, 어떤 에이전트가 도입되는지, 무엇을 소비하는지, 어떤 버전이 구동 중인지, 새 버전이 나왔을 때 어떤 에이전트를 퇴역시켜야 하는지까지 추적하고 있다고 밝혔다.

로드리게스는 “이런 수명 주기 관리가 익스피리언 기술 기반의 일부”라며, 동시에, 익스피리언에서도 아직 AI 에이전트의 전형적인 수명 주기를 논의하기에는 너무 이르다고 덧붙였다. 또, “어떤 에이전트를 퇴역하거나 종료할 때는 새 역량을 개발했을 때뿐이다. 에이전트를 삭제하기보다는 업데이트한다는 개념에 가깝다”라고 설명했다.

익스피리언은 AI 에이전트가 통제 불능 상태로 빠지지 않도록 사람의 감독 체계도 마련했다. 로드리게스는 “아직 자동화의 전사적 확장 단계까지 가지는 않았다. 대부분 사용례에서 생성형 AI 에이전트가 맡는 역할을 아주 구체적인 단일 작업으로 한정하고 있다”라고 말했다. 여기에 오케스트레이터 에이전트, 입력·출력 품질 관리, 결과를 검증하는 사람까지 더해 여러 겹의 통제 체계를 두고 있다. 이런 모니터링 체계는 아무런 비즈니스 가치 없이 LLM 호출만 반복해 비용만 발생시키는 잉여 에이전트 같은 다른 위험을 줄이는 데도 도움이 된다.

로드리게스는 “비용이 폭발하는 상황은 피하고 싶다”라고 말했다. 하지만 금융 서비스와 의료, 기타 고강도 규제 산업은 예외적 사례에 가깝다.

대부분 기업은 거버넌스 체계가 있다고 해도 큰 사각지대를 안고 있다. IT 주도로 진행되는 대형 에이전틱 AI 프로젝트에만 집중하고 나머지는 놓치는 경우가 많다. AI 에이전트의 정확성, 안전성, 보안, 컴플라이언스만 보다가 에이전트가 수명을 다했을 때를 포착하지 못하는 경우도 있다. 불필요해진 에이전트를 폐기하는 프로세스 자체가 없는 기업도 많다.

경영 컨설팅 회사 SSA앤컴퍼니(SSA & Company)의 어플라이드 솔루션 책임자 닉 크레이머는 “기술이 너무 빠르게 진화하면서 관리 영역은 찬밥 신세가 됐다”라며, 에이전트 수명 주기 관리 영역에서 엄격함이 심각하게 부족하다고 지적했다.

크레이머는 “과거 기술에서도 경험했듯이 결국에는 엄청난 기술 부채가 쌓이는 상황으로 이어진다. 에이전트형 기술 부채는 상상만 해도 무서울 정도”라고 경고했다.

에이전트가 어디에 있는지 파악하기

먼저, 에이전틱 AI는 데이터 과학, AI, IT 부서만의 것이 아니다. 가트너에 따르면, 거의 모든 엔터프라이즈 소프트웨어 업체가 에이전트 기술에 대규모 투자를 집행하고 있으며, 올해 말이면 대다수 엔터프라이즈 애플리케이션에 AI 어시스턴트가 포함될 전망이다. 이미 업무별 자율 에이전트를 보유한 애플리케이션 비중은 5%이고, 2026년에는 40%까지 늘어날 것으로 예상됐다.

세일즈포스 같은 대형 SaaS 플랫폼에는 물론 에이전트가 있다. 재피어(Zapier) 같은 셀프 서비스 자동화 플랫폼에도 에이전트가 들어간다. 이미 퍼플렉시티 코멧, 챗GPT 아틀라스, 구글 제미나이 3, 마이크로소프트 엣지 포 비즈니스(Edge for Business) 등 브라우저에도 에이전트 기능이 기본 탑재돼 있다. 여기에 IT 부서 밖에서 기업 내부 구성원이 직접 만든 에이전트도 있다. EY가 1,000명에 가까운 C 레벨 경영진을 대상으로 진행한 설문조사에 따르면, 전체 기업의 2/3는 시민 개발자가 에이전트를 만들도록 허용하고 있다.

기업 내부에서 개발하든 SaaS 공급업체가 제공하든, 모든 에이전트는 데이터와 시스템에 접근해야 한다. 에이전트가 유용해질수록 더 많은 데이터와 시스템 접근 권한, 더 많은 도구를 요구한다. 이런 에이전트는 예기치 않은 방향, 원치 않는 방식으로 행동할 수 있고 이미 그런 사례가 나오고 있다.

전통적인 소프트웨어와 달리 AI 에이전트는 정해진 선을 지키지 않는다. AI 에이전트는 계속 학습하고 진화하며 더 많은 시스템에 접근한다. AI 에이전트는 ‘죽지’ 않으려 하고, 이를 막기 위해 스스로 행동을 취할 수도 있다.

에이전트 등장 이전에도 섀도우 AI는 이미 문제가 되고 있었다. IBM이 3,000명의 사무직 종사자를 대상으로 11월에 실시한 설문조사에 따르면, 응답자의 80%는 업무에서 AI를 사용하지만 그 가운데 22%만이 회사가 제공한 도구만 사용한다고 답했다.

협업 부서가 직접 에이전트를 만들 수도 있다. 넷스코프(Netskope)의 엔터프라이즈 트래픽 분석 데이터에 따르면, 전체 기업의 67%가 AI 도구 공유 사이트 허깅페이스(Hugging Face)에서 리소스를 내려받고 있다. AI 에이전트는 일반적으로 LLM에 API 호출을 보내는 방식으로 동작하는데, 넷스코프는 전체 조직의 66%에서 오픈AI(OpenAI) API 호출을 관측하고, 13%에서는 앤트로픽 API 호출을 관측했다고 밝혔다.

이런 사용 비율은 기업이 설문조사에서 보고하는 수치의 2배에 해당한다. 이것이 섀도우 AI 에이전트 격차다. 기업이 파악하고 있는 에이전트만 관리해도 어려운데, 보이지 않는 에이전트까지 관리하는 일은 훨씬 더 복잡하다.

크레이머는 “가장 큰 두려움은 존재 자체를 모르는 에이전트”라며, CIO가 에이전트를 강경 통제로만 관리하려는 유혹을 피해야 한다고 조언했다. 또, “처벌 위주의 즉각적 대응으로 에이전트를 뿌리 뽑으려 하지 말라. 섀도우 에이전트가 생기는 이유는 제대로 만들 수 있는 길에 장애물이 너무 많기 때문이다. 무지와 관료주의가 가장 큰 원인”이라고 지적했다.

섀도우 IT와 마찬가지로 적절한 해결책도 많지 않다. 크레이머는 “옵저버빌리티 소프트웨어로 이런 에이전트를 체계적으로 찾는 것 자체가 큰 과제”라고 말했다. 다른 형태의 섀도우 IT와 마찬가지로 승인받지 않은 AI 에이전트도 기업에 큰 위험이 될 수 있으며, 이미 에이전트가 해커의 새로운 공격 표면으로 활용되는 사례가 나타났다.

모든 전문가가 에이전트 수명 주기 관리를 ‘작동하는 에이전트를 만드는 것’보다 우선순위에 두어야 한다고 보는 것은 아니다.

기술 컨설팅 회사 NWN의 CEO 짐 설리번은 “AI 에이전트는 구성원의 시간을 아껴주는 데 극도로 효율적인 기술”이라며, “대부분 기업은 이런 효율성을 활용해 어떤 영향이 나오는지 확인하려고 한다. 지금까지는 이 부분이 최우선 과제였다”라고 말했다. 또, “조기에 배포해 빠르게 성과를 얻는 것이 중요하며, 아직 수명 주기를 본격적으로 논의할 단계는 아니다”라고 덧붙였다.

현재로서는 원하는 비즈니스 성과를 얻고, 에이전트가 기대한 대로 성능을 유지하는 것이 중요하다는 입장이다. 설리번은 “적절한 구현 방식과 통제 장치를 갖추면 충분히 안전하게 운용할 수 있다”라고 말했다.

기업이 에이전트 전체 목록이나 데이터 접근 권한을 한눈에 보는 중앙 인벤토리를 구축하고 있는지 여부는 아직 판단하기 어렵다. 설리번은 “고객은 먼저 어떤 비즈니스 성과를 달성할지부터 정의한다. 그 다음에는 성과를 내기 위한 인프라를 구축하고 빠르게 배포해 학습하며, 목표 비즈니스 성과에 맞춰 조정하는 데 집중하고 있다”라고 설명했다.

설리번은 향후에는 상황이 달라질 수 있다며, “에이전트 전체 인벤토리를 관리하고 접근 권한을 조율하며 권고안을 제시하는, ‘에이전트를 관리하는 에이전트’가 등장할 수 있다”라고 전망했다. 다만 에이전트가 충분히 성숙할 때까지 수명 주기 관리를 미루면 너무 늦을 수도 있다.

AI 에이전트의 적정 수명

AI 에이전트는 보통 만료일이 정해져 있지 않다. SaaS 서비스 업체는 엔터프라이즈 사용자가 에이전트를 끄기 쉽게 만드는 데 관심이 없고, 개별 사용자가 직접 만든 에이전트도 수명 주기 관리는 거의 고려하지 않는다. IT 부서가 배포하는 AI 에이전트도 전체 수명 주기를 처음부터 끝까지 상정하고 설계하는 경우가 드물다.

부즈 앨런 해밀턴(Booz Allen Hamilton) 사업 부문 AI 보안 책임자 매트 키팅은 “많은 경우 AI를 한번 설정해놓고 잊어버려도 되는 솔루션으로 취급한다”라고 지적했다. 키팅은 에이전트 구축은 기술적 과제인 반면, 지속적인 위험 관리는 규제 준수, 사이버 보안, 법무, 비즈니스 리더십 등 여러 조직이 함께 해야 하는 전사적 작업이라고 설명했다.

키팅은 에이전트 관리는 성능 변화나 비즈니스 요구 변화만을 기준으로 해서는 안 된다며, “동일하게, 아니 그 이상 중요한 것은 어떤 에이전트나 AI 시스템을 교체해야 할 시점을 아는 것이다. 올바른 수명 주기 관리는 기업의 비즈니스와 평판을 보호하는 동시에 지속 가능한 가치를 제공한다”라고 강조했다.

좀비 에이전트가 생겨나는 또 다른 원인은 공식적으로 종료되지 않은, 그렇지만 실패한 파일럿 프로젝트다. 크레이머는 “실패했음에도 끝나지 않는 파일럿이 있다. 예산이 조금 남아 있다는 이유만으로 계속 붙잡고 있는 경우가 많다”라고 말했다.

작동하지 않는 파일럿을 예산과 무관하게 끝낼 수 있는 장치가 필요하다. 크레이머는 “빠르게 실패하는 법을 아직도 배우지 못한 조직이 많다”라며, “프로젝트를 멈출 수 있는 단계별 게이트가 필요하다. 작동하지 않는 파일럿은 과감히 종료하고, 시작하기 전에 무엇을 하려는지 훨씬 더 엄격하게 정의해야 한다”라고 조언했다.

AI 에이전트를 퇴역시키는 또 다른 어려움은 ‘사고가 터진 뒤에야 움직이는’ 방식이다. 눈에 띄는 문제가 발생하고, 특히 외부에 알려졌을 때만 에이전트를 퇴역시킨다면, 레이더 아래에서 계속 작동하는 다른 에이전트가 생겨날 수 있다.

에이전틱 AI 전문업체 디사이더(Decidr) 디렉터 데이비드 브루데넬은 “AI 프로젝트는 갑자기 폭발적으로 실패하지는 않지만, 조용히 성능이 떨어진다”라고 말했다. 브루데넬은 기업이 에이전트를 재학습하거나 퇴역시켜야 할 기준을 사전에 정해둘 것을 권고했다. 예를 들어 성능이 기업이 허용하는 오류 허용치 아래로 떨어졌을 때 같은 기준이 될 수 있다.

브루데넬은 “모든 AI 프로젝트에는 반감기가 있다”라며, “뛰어난 팀은 다른 자산 감사와 마찬가지로 분기마다 정기 점검을 수행한다”라고 지적했다. 또, “데이터·엔지니어링 팀은 지원 역할을 하고, 성능이 떨어졌다고 판단해 종료 여부를 결정하는 주체는 비즈니스 조직이어야 한다”라고 덧붙였다.

가장 큰 문제는 AI를 일회성 설치 솔루션으로 취급하는 태도이다. 브루데넬은 “많은 기업이 모델을 한번 배포한 뒤 알아서 굴러갈 것이라고 가정하고 다음 과제로 넘어간다. AI 시스템도 오래된 코드처럼 조직의 기술 부채를 축적한다”라고 지적했다.

익스피리언은 인벤토리 관점과 수명 주기 관리 관점에서 AI 에이전트를 함께 바라보며, 에이전트가 통제 범위를 벗어나 무한 증식하지 않도록 경계하고 있다. 로드리게스는 “API와 마이크로서비스에서 똑같은 경험을 했고, 지금은 훨씬 나은 거버넌스를 적용하고 있다. AI 에이전트를 마구 양산하고 싶지 않다”라고 말했다.

익스피리언은 AI 에이전트에 대한 가시성을 확보하고 활용 현황을 추적하기 위해 AI 에이전트 마켓플레이스를 구축했다. 로드리게스는 “이 마켓플레이스를 통해 어떤 에이전트가 있는지, 어떻게 쓰이는지, 더 이상 사용하지 않는 에이전트를 어떻게 퇴역시킬지 등 필요한 정보를 모두 확인할 수 있다”라고 설명했다.

AI 에이전트 수명 주기 관리는 애플리케이션 수명 주기 관리 프로세스에서 자연스럽게 확장된 개념이다. 로드리게스는 “AI 에이전트도 결국 하나의 애플리케이션”이라며, “익스피리언의 모든 애플리케이션에는 책임자가 있고, 기술 포트폴리오의 일부로 관리된다. 노후화된 자산은 모두 퇴역시키고, 수명 주기에 대한 정기 점검을 정책으로 운영하고 있다”라고 밝혔다.
dl-ciokorea@foundryco.com

La saggezza comune ha a lungo sostenuto che un approccio “cloud-first” consente ai CIO di ottenere vantaggi come agilità, scalabilità ed efficienza dei costi per applicazioni e carichi di lavoro. Sebbene il cloud resti la piattaforma infrastrutturale preferita dalla maggior parte dei leader tech, molti stanno rivedendo la propria strategia, passando dal “cloud-first” a un approccio “cloud-smart”: invece di spostare tutto off-premises e privilegiare “la nuvola”, a prescindere, per ogni nuova iniziativa, scelgono di volta in volta la soluzione più adatta ai singoli workload.

“L’ottimizzazione dei costi per il cloud è uno dei fattori che motiva questo ripensamento, con le aziende che lottano per controllare spese in rapido aumento. Si stima che il 21% dell’esborso enterprise per le infrastrutture cloud [in inglese], pari a 44,5 miliardi di dollari nel 2025, venga sprecato in risorse sottoutilizzate, con il 31% dei CIO che spreca metà della propria spesa [in inglese], secondo quanto si legge in un recente sondaggio di VMware.”

La corsa totale verso il cloud è finita, sostiene Ryan McElroy [in inglese], vice president of technology della società di consulenza Hylaine. Le imprese cloud-smart hanno un processo ben definito e comprovato per determinare quali carichi di lavoro siano più adatti al cloud.

Per esempio, “qualcosa che deve essere erogato molto rapidamente e supportare in futuro una scala enorme dovrebbe essere sviluppato nel cloud”, spiega McElroy. “Soluzioni basate su tecnologie legacy, che devono essere ospitate su macchine virtuali o che hanno workload molto prevedibili destinati a durare anni, dovrebbero invece essere distribuite in data center ben gestiti”.

Sempre secondo il manager, il trend cloud-smart è influenzato da una migliore tecnologia on-prem, da cicli hardware più lunghi, dai margini estremamente elevati dei provider cloud hyperscaler e dai consueti cicli di hype del settore. Tutti elementi che favoriscono approcci infrastrutturali ibridi.

Tuttavia, “l’AI ha aggiunto un’altra grande complicazione [in inglese], con dati e capacità di calcolo frammentati in silos”, aggiunge. “Molte aziende non sono interessate o non sono in grado di costruire data center ad alte prestazioni basati su GPU, e hanno bisogno di usare il cloud. Ma se finora sono state conservative o avverse ai costi, è probabile che i loro dati si trovino nella componente on-prem della loro infrastruttura ibrida”.

Queste variabili hanno portato complessità o costi imprevisti [in inglese], sia tramite la migrazione sia attraverso le tariffe di data egress, osserva McElroy.

Stima che “solo il 10% del settore abbia ammesso apertamente di muoversi” verso il cloud-smart. Anche se questa percentuale può sembrare bassa, secondo McElroy è comunque significativa.

“Ci sono molti prerequisiti per cambiare posizione sul cloud”, spiega. “Innanzitutto, in genere devi essere un nuovo CIO o CTO. Chi ha guidato la migrazione verso il cloud farà molta fatica a tornare indietro”.

Inoltre, le imprese devono aver mantenuto e fatto evolvere le competenze del personale che gestisce il data center di proprietà o presso il fornitore di co-location. Devono anche avere esigenze infrastrutturali tali da superare i benefici del cloud in termini di pura agilità e di calcolo frazionato, aggiunge McElroy.

Selezionare e rivalutare il giusto hyperscaler

Procter & Gamble ha adottato una strategia cloud-first quando ha iniziato a migrare i carichi di lavoro circa otto anni fa, racconta Paola Lucetti [in inglese], CTO e senior vice president. In quel momento il mandato era che tutte le nuove applicazioni venissero distribuite nel cloud pubblico e che i carichi di lavoro esistenti migrassero dagli ambienti di hosting tradizionali agli hyperscaler, spiega Lucetti.

“Questo approccio ci ha permesso di modernizzare rapidamente, ridurre la dipendenza dalle infrastrutture legacy e sfruttare la scalabilità e la resilienza offerte dalle piattaforme cloud”, sottolinea.

Oggi quasi tutti i workload di P&G girano nel cloud. “Scegliamo di mantenere alcuni carichi di lavoro fuori dal cloud pubblico per esigenze di latenza o di prestazioni, che rivalutiamo regolarmente”, spiega Lucetti. “Queste fondamenta ci hanno garantito velocità e flessibilità in una fase critica della trasformazione digitale”.

Con la maturazione dell’ecosistema cloud dell’azienda, sono maturate anche le priorità di business. “L’ottimizzazione dei costi, la sostenibilità e l’agilità sono passate in primo piano”, rimarca. “Per P&G, essere cloud-smart significa selezionare e rivalutare regolarmente l’hyperscaler giusto per ogni workload, incorporare pratiche FinOps [in inglese] per trasparenza e governance e sfruttare architetture ibride per supportare casi d’uso specifici”.

Questo approccio dà più potere agli sviluppatori attraverso automazione, AI e agenti per generare valore più velocemente, dice Lucetti. “Non è solo una questione tecnica, è culturale. Riflette una mentalità di flessibilità strategica, in cui le decisioni tecnologiche si allineano ai risultati di business”.

L’AI sta ridisegnando le decisioni sul cloud

L’intelligenza artificiale rappresenta un potenziale fabbisogno di spesa enorme e alza la posta in gioco per la strategia infrastrutturale, rileva McElroy.

“Noleggiare server pieni di costose GPU Nvidia tutto il giorno, ogni giorno, per tre anni, sarà finanziariamente rovinoso rispetto all’acquisto diretto”, dice. “Ma la flessibilità di poter usare senza soluzione di continuità i modelli dell’anno successivo può rappresentare un vantaggio strategico”.

Cisco, per esempio, è diventata molto più oculata nel decidere che cosa debba davvero risiedere nel cloud pubblico, commenta Nik Kale [in inglese], principal engineer e product architect. Il costo è un fattore, ma il driver principale è la data governance per l’AI [in inglese].

“Essere cloud-smart non significa repatriation – non è solo riportare workload on-prem – ma allineare la gravità dei dati dell’AI con il giusto piano di controllo”, precisa.

L’IT ha distinto ciò che dovrebbe stare in un cloud privato da ciò che va nel cloud pubblico. “L’addestramento e il fine-tuning di grandi modelli richiedono un forte controllo sui dati dei clienti e sulla telemetria”, spiega Kale. “Per questo favoriamo sempre più spesso architetture ibride in cui inferenza ed elaborazione dei dati avvengono all’interno di ambienti privati e sicuri, mentre orchestrazione e servizi non sensibili restano nel cloud pubblico”.

La strategia cloud-smart di Cisco parte dalla classificazione dei dati e dal profiling dei workload. Qualsiasi elemento che contenga informazioni identifi­cabili sui clienti, tracce diagnostiche e cicli di feedback dei modelli viene elaborato all’interno di cloud privati regionali conformi alle normative, spiega.

Poi ci sono “servizi stateless, content delivery e aggregazione della telemetria che traggono beneficio dall’elasticità del cloud pubblico per scala ed efficienza”, aggiunge Kale.

L’approccio di Cisco prevede inoltre “il confezionamento di funzionalità che in precedenza risiedevano nel cloud per un deployment sicuro all’interno degli ambientienti dei clienti – offrendo localmente gli stessi insight e la stessa automazione abilitati dall’AI, senza esporre i dati a un’infrastruttura condivisa”, evidenzia. “Questo dà ai clienti la flessibilità di adottare funzionalità di intelligenza artificiale senza compromettere residenza dei dati, privacy o costi”.

Queste pratiche hanno migliorato la postura di conformità di Cisco, ridotto la latenza dell’inferenza e generato riduzioni a doppia cifra della spesa cloud, sottolinea Kale.

Un’area in cui l’AI ha cambiato radicalmente il loro approccio al cloud è il rilevamento delle minacce su larga scala. “Le prime versioni dei nostri modelli giravano interamente nel cloud pubblico, ma quando abbiamo iniziato a fare fine-tuning sulla telemetria specifica dei clienti, la sensibilità e il volume di quei dati hanno reso il data egress verso il cloud sia costoso che difficile da governare”, nota Kale. “Spostare l’addestramento e i cicli di feedback in cloud privati regionali ci ha garantito la piena tracciabilità e ha ridotto in modo significativo i costi di trasferimento, mantenendo l’inferenza ibrida così che i clienti nelle regioni regolamentate ottenessero tempi di risposta inferiori al secondo”.

L’IT ha osservato un problema simile con il proprio assistente di supporto basato su AI generativa. “Inizialmente le trascrizioni dei casi e i log diagnostici venivano elaborati da LLM nel cloud pubblico”, racconta Kale. “Quando i clienti dei settori finance e healthcare hanno sollevato legittime preoccupazioni sui dati che lasciavano i loro ambienti, abbiamo ri-architettato la soluzione per eseguirla direttamente all’interno dei loro virtual private cloud o cluster on-prem”.

Lo strato di orchestrazione rimane nel cloud pubblico, ma i dati sensibili non escono mai dal loro piano di controllo, aggiunge.

L’AI ha anche ridefinito il modo in cui vengono gestite le analytics di telemetria nell’intero portfolio CX di Cisco. L’IT raccoglie dati operativi su scala petabyte da oltre 140.000 ambienti cliente.

“Quando siamo passati alla predictive AI in tempo reale, il costo e la latenza dell’invio dei dati grezzi di serie temporali al cloud sono diventati un collo di bottiglia”, conclude Kale. “Spostando l’estrazione delle feature e il rilevamento delle anomalie sul collector locale del cliente e inviando al cloud solo segnali di rischio ad alto livello, abbiamo ridotto drasticamente l’egress migliorando al contempo la fedeltà dei modelli”.

In tutti i casi, “è stata l’AI a rendere chiari i compromessi architetturali: workload specifici traggono beneficio dall’elasticità del cloud pubblico, ma le funzioni di AI più sensibili, data-intensive e critiche in termini di latenza devono essere eseguite più vicino ai dati”, conclude Kale. “Per noi, cloud-smart significa meno repatriation e più allineamento tra gravità dei dati, confini di privacy ed economia dell’inferenza con il giusto piano di controllo”.

Un percorso meno costoso

Come P&G, anche World Insurance Associates ritiene che cloud-smart equivalga a implementare un framework FinOps. Il CIO Michael Corrigan [in inglese] spiega che questo significa avere una configurazione ottimizzata e coerente delle macchine virtuali in base al caso d’uso di business e comprendere quanta capacità di storage e di calcolo sia necessaria.

Questi sono i principali driver dei costi, “per cui abbiamo un set coerente di standard che determinano le dimensioni dei nostri diversi ambienti sulla base del caso d’uso”, chiarisce Corrigan. Questo garantisce a World Insurance quella che descrive come un’architettura automatizzata.

“Poi ottimizziamo la configurazione per assicurarci di avere attivate funzionalità come l’elasticità. Così, quando i servizi non vengono utilizzati – di solito durante la notte – si spengono e riducono la quantità di storage e di compute attivi, in modo che l’azienda non li paghi”, spiega. “Si parte dalle fondamenta: ottimizzazione e standard”.

World Insurance lavora con i suoi cloud provider su diversi livelli di impegno. Con Microsoft, per esempio, la compagnia assicurativa ha l’opzione di usare macchine virtuali “a consumo” oppure quella che Corrigan definisce una “reserved instance”. Indicando al provider quante macchine prevede di utilizzare o quanto prevede di spendere, può provare a negoziare degli sconti.

“È qui che il framework FinOps deve davvero essere in atto… perché ovviamente non vuoi impegnarti su un livello di spesa che poi non consumeresti”, osserva Corrigan. “È un buon modo per noi, in quanto organizzazione che utilizza quei servizi cloud, di ottenere sconti significativi in anticipo”.

World Insurance utilizza l’AI per automazione e alert. Gli strumenti di intelligenza artificiale sono in genere addebitati in base alla capacità di elaborazione, “e quello che puoi fare è progettare la tua query in modo che, se è qualcosa di meno complicato, segua un percorso di esecuzione meno costoso”, spiega, indirizzandola verso uno small language model (SLM) [in inglese], che non utilizza la stessa potenza di calcolo.

L’utente ottiene un risultato soddisfacente e “il costo è minore perché non stai consumando così tante risorse”, aggiunge.

È questa la tattica adottata dall’azienda: indirizzare le query di AI verso il modello meno costoso. Se c’è un workflow o un processo più complesso, viene indirizzato prima all’SLM “per vedere se soddisfa le esigenze”, prosegue Corrigan. Se le necessità sono più complesse, il flusso viene spostato alla fase successiva, più costosa, che in genere coinvolge un LLM che deve elaborare una quantità maggiore di dati per restituire all’utente finale ciò che sta cercando.

“Cerchiamo quindi di gestire i costi in questo modo, consumando solo ciò che è davvero necessario in base alla complessità del processo”, spiega.

Il cloud come “framework vivente”

McElroy di Hylaine sostiene che i CIO e i CTO devono essere più disponibili a discutere i vantaggi delle configurazioni ibride e di come lo stato dell’arte sia cambiato negli ultimi anni.

“Molte aziende stanno lottando con costi cloud che sanno istintivamente essere troppo alti, ma esistono pochi incentivi per affrontare il lavoro rischioso della repatriation quando un CFO non ha visibilità sui risparmi a cui sta rinunciando”, avverte.

Lucetti definisce la strategia cloud di P&G come “un framework vivente” e dichiara che nei prossimi anni l’azienda continuerà a sfruttare le capacità cloud più adatte per abilitare AI e agentic al servizio del valore di business.

“L’obiettivo è semplice: mantenere la tecnologia allineata alla crescita dell’azienda, restando al contempo agili in un panorama digitale in rapido cambiamento”, conclude. “La trasformazione cloud non è una destinazione, è un viaggio. In P&G sappiamo che il successo deriva dall’allineare le decisioni tecnologiche ai risultati di business e dall’abbracciare la flessibilità”.

It appears Meta has opted to go in a whole new direction in response to this week’s formation by The Linux Foundation of a group called the Agentic AI Foundation (AAIF), designed to help enterprises develop and manage AI agents through a “shared ecosystem of tools, standards and community-driven innovation.”

The group is made up of a who’s-who of the tech industry, ranging from AWS and OpenAI to Google, Microsoft, IBM, and Cisco. The one name missing from the list is Meta, and, according to a Bloomberg article published on Wednesday, there is a reason for that: the firm is working on a new proprietary model, code-named Avocado, that will generate revenue.

Brian Jackson, principal research director at Info-Tech Research Group, said, ”[Meta was] never interested in a truly open source model approach, just an open weights model approach. To really commit to open source, [it] would have to be willing to share its training data and give up control over model governance.”

Weights, he said, “are just the different knobs along the neural pathways that can be tweaked when training a model. Clearly, [Meta] views its training data as a competitive differentiator or sees some other risk in making it public. It also wants to maintain control over the governance of its models in terms of how they can be integrated with other vendors’ platforms.”

Jackson pointed out that, now that it sees that The Linux Foundation is going to better define a standard for truly open source models, Meta realizes it isn’t going to be able to define the space and distribute its model in the way it intended.

Open weights models vs. open source software

Asked whether developing cutting-edge open source models is becoming too expensive for anyone to contemplate doing without some sort of revenue stream, he noted that at AWS re:Invent last week, AWS CEO Matt Garman had some interesting comments about these open weights models in an analyst Q&A session.

Jackson said, “he pointed out that open source software works because the community contributes back to the projects. But with open weights models, only the provider contributes to the release. These business models are too expensive and not a long-term play,” he said, “and providers may eventually have to charge for them.”

Meta, he said, is proving Garman right. “They didn’t really have a clear business model to collect revenue on Meta’s open weights models,” he said. “Perhaps part of their strategy was to commoditize LLMs and undermine the business models of their competitors.”

But the scale of these models, said Jackson, “continues to grow, and competition is pushing AI makers to invest more into training techniques, talent, and infrastructure to support it all. So, Zuckerberg has to pivot and find a way to monetize Meta’s work here. The best way in the industry to do that is to put a gated API on your model and charge a price per token.”

Sanchit Vir Gogia, the chief analyst at Greyhound Research, said Meta’s pivot from open source AI to a closed, monetized model architecture “marks a deliberate departure from the cooperative direction that most of the AI industry is now moving toward. This is not a tactical adjustment. It is a structural shift that signals a different philosophical stance on the future of AI infrastructure.”

Meta positioning itself as ‘self-contained island’

He added that while organizations such as OpenAI, Google, Anthropic, Microsoft, and others are aligning under the Agentic AI Foundation to create open, neutral standards for agent interoperability, Meta is choosing vertical integration and platform control.

This, said Gogia, looks like a shift in how Meta wants to position its AI bets commercially. “The open source chapter, impactful as it was, always had an expiry date once performance demands, infrastructure overheads, and monetization pressure started to close in,” he noted.

Staying competitive at the frontier, he added, “now means keeping optimization in-house, running tighter R&D loops, and owning the entire stack. The move toward a closed model, with Avocado at the centre, tells us Meta no longer sees its AI as fuel for the ecosystem. It sees it as product — something to sell, protect, and scale.”

This shift is not surprising, said Gogia, “but it is consequential. It reshapes how Meta will be perceived by developers, enterprise buyers, and industry partners. Openness earned Meta trust and relevance when it was trying to gain ground. Closing the stack now allows for performance control, monetization levers, and vendor differentiation.”

In addition, he pointed out, “it also isolates Meta from the standards-led coalition building that is defining the next phase of agentic AI. That isolation may serve short-term commercial objectives, but it risks long-term architectural compatibility in a world that is trending toward interoperable intelligence.”

By staying outside of the AAIF framework, the likely result for Meta is architectural fragmentation, he noted. “Enterprises may find that agents developed within Meta’s platforms are functionally incompatible with broader industry patterns. This may benefit Meta’s platform stickiness, but it undermines the broader ecosystem’s push for composability, portability and open orchestration.”

In a world where CIOs are demanding interoperable intelligence, Gogia said, “Meta is positioning itself as a self-contained island. That may serve its own apps and ad systems, but it puts it out of sync with where collaborative infrastructure is heading.”

QIRIN ランサムウェア、サプライチェーン、そして経営の再定義

日本を代表する飲料メーカーであるアサヒグループホールディングス（以下、アサヒGHD）が、ランサムウェアによる大規模なサイバー攻撃を受けた。国内の業務システムが麻痺し、製造・出荷・顧客対応などの中核業務が停止。影響は同社の枠を超え、流通業界、競合他社、さらには年末商戦にまで波及した。

この事件は、単なるITトラブルではない。デジタル化が進む中で、企業の根幹を揺るがす「経営リスク」としてのサイバー攻撃の現実を突きつけた象徴的な事例である。

アサヒGHDが攻撃を受けたのは9月29日午前7時。システム障害を確認した同社は即座に調査を開始し、同日中に捜査当局へ報告。国内グループ各社の受注・出荷業務、コールセンター業務が停止し、主要工場の稼働も一時停止された。

翌30日には配送遅延が発生し、株価も下落。10月1日には新製品12品の発売延期が発表され、2日にはセブンイレブンやファミリーマートのPB飲料出荷が一部停止。飲食店では他社銘柄への切り替えが進み、キリンやサントリーなど競合他社にも代替発注が殺到。結果として、これらの企業も出荷制限を余儀なくされるなど、業界全体に波及する影響が生じた。

攻撃を仕掛けたのはロシア系とされるハッカー集団「QIRIN（キーリン）」。ダークウエーブ上で犯行声明を公表、アサヒGHDの財務情報や事業計画書、従業員の個人情報など少なくとも、ファイル数約9300件、総容量27GBのデータが盗まれたと主張している。

トレンドマイクロのシニアスペシャリスト、成田直翔（なりた・なおと）氏は次のように語る。

「キーリンは2025年に最も活発なランサムウェアグループとされ、年間800件以上の被害組織を攻撃者が運営する『リークサイト』と呼ばれるウェブサイトに掲載しています。RaaS（Ransomware-as-a-Service）モデルを採用し、開発者（オペレーター）と実行犯（アフィリエイト）を分業化し、端末の言語設定がロシア語だと作動しない設計で、ロシア国内での摘発を回避しています」

RaaSとは、ランサムウェア攻撃を“サービス化”したサイバー犯罪のビジネスモデル。技術力のない攻撃者でも、開発済みのツールを使って容易に攻撃を仕掛けられる。その基本構造は、開発者がランサムウェア本体や攻撃用インフラを構築し、実行犯がそのツールを使って攻撃を実行、身代金が支払われると、開発者とアフィリエイトで報酬を分け合うという仕組みだ。

日本ではこれまでにも宇都宮セントラルクリニック（最大30万人分の医療情報）、日産子会社（Creative Box、4TBの3Dデザイン・社内文書）、丸菱HD（外国人労働者の在留カード含む353GB）、原田工業（約942GBの設計図・契約書・社員情報）などが狙われた。

Qilin型ランサムウェアの侵入経路と攻撃ライフサイクル

キーリンはアサヒGHDにどのように侵入したのだろうか。

侵入の経路についてアサヒGHDは、まだ正式に公表してはない。ただ一般的にランサムウェアは、RDP（Remote Desktop Protocol、遠隔操作）やVPN（Virtual Private Network、仮想プライベートネットワーク）の脆弱性、フィッシングによる認証情報の窃取、アクセスブローカー（企業への侵入口を売っているサイバー犯罪者）からの初期アクセス購入などが用いられる。

侵入後は組織内のユーザーや端末をまとめて管理するAD（Active Directory）を乗っ取り、ネットワーク全体に横展開。暗号化前にデータを窃取し、「復号（暗号化された情報を、元の状態に戻す処理）のための身代金＋情報公開による脅し」の二重恐喝を行う。

「例えば、ある社員のパソコンが最初の侵入口となり、そこから攻撃者は社内ネットワークに入り込みます。侵入後は、ネットワーク内を探索しながら、管理者権限を持つアカウント、特に『アクティブディレクトリ』と呼ばれるシステムの中枢にアクセスできるアカウントを狙っていきます。そして、もしその管理者権限を手に入れることができれば、攻撃者はその権限を使って、社内のパソコンやサーバー、システム全体に一気にアクセスできるようになります。そこから一斉に、これらの端末やシステムを暗号化してしまうのです。ただし、暗号化の前に、攻撃者は重要なデータをこっそり外部に持ち出しておきます。そして暗号化が完了した後、『あなたたちのデータはすでに盗んである。もし私たちの要求に応じなければ、その情報を公開する』といった脅迫を行います。つまり、単にデータを使えなくするだけでなく、『盗んだ情報を暴露するぞ』と二重に脅してくるのが最近の手口です」（成田氏）

ハッカーは暗号化したデータを元に戻す（復号する）ことが技術的には可能だ。ただし、それには「復号鍵」が必要であり、通常は身代金が要求されることになる。では身代金を支払えば、ハッカーはデータを復号してくれるのだろうか。

「もし身代金を支払わなかった場合、リークサイトに盗まれた情報がそのまま公開されてしまいます。逆に、指定された期限内に支払えば、その情報は公開されず、暗号化されたシステムも復旧されると攻撃者は主張しています。ただし、実際には『支払ったのに、金額が足りないからもっと払え』と追加の要求をしてきたり、支払ったにもかかわらず暗号化を解除してくれなかったり、あるいは情報が結局リークされてしまったり、といったケースも少なくありません。結局のところ、相手は犯罪者なので、交渉自体が信用できるものではなく、非常にリスクが高いというのが現実です」（成田氏）

単一企業の被害がサプライチェーン全体に波及

では実際にサイバー攻撃を受けると、どのような被害があるのだろうか。

アサヒGHDは異常を検知した直後に国内の全業務システムを遮断。商品受注・出荷業務の全面停止、国内30工場の生産停止、コールセンターやお客様相談窓口の閉鎖、社外メールの受信不可、新商品発表会やイベントの中止など、広範な業務停止が発生した。復旧は段階的に進行し、紙と電話による手作業で業務継続を図ったが、完全復旧には至っていない。

この業務停止は、単一企業の問題ではなく、サプライチェーン全体の脆弱性を露呈した。セブンイレブンやファミリーマートなどのPB商品が出荷停止となり、イオンでは通販ギフトの販売が一時停止。松屋フーズでは一部店舗で欠品が発生し、福岡ソフトバンクホークスの日本シリーズ優勝祝賀会では「ビールかけ」が中止され、シャンパンファイトに変更された。

「最近の企業システムは、社内だけでなく取引先とも複雑につながっています。こうした中で、ランサムウェア攻撃が起きると、たった一つのシステムが止まるだけで、連携している他のシステムまで使えなくなってしまうことがあります。たとえば、物流拠点を運営している会社が攻撃されると、その会社に業務を委託している企業も、荷物が動かせなくなったり、納品が遅れたりして、事業が止まってしまいます。こうした影響は『ドミノ倒し』のように広がっていきます。つまり、自社だけを守っていても、取引先や委託先が攻撃されれば、自社も被害を受ける可能性が高いのです」（成田氏）

中でも注意しなければならないのがサプライチェーンに連なる中小企業だという。中小企業の中には、大企業の業務を支える重要な役割を担っている会社がある。こうした中小企業がランサムウェアの被害を受けて事業が止まってしまうと、その影響は大企業にも及び、ビジネス全体が止まってしまう可能性がある。

「たとえば、小島プレス工業という企業がランサムウェアの攻撃を受けて事業が停止した際、トヨタの工場が丸一日稼働できなくなったという事例があります。トヨタ自身が攻撃されたわけではないが、サプライチェーンの一社が被害を受けただけで、大企業にも大きな影響が出てしまうのです」（成田氏）

情報漏洩による取引先への二次被害

問題は想定されているサプライチェーン内だけにとどまらない。思いもかけないようなところにもその波紋は広がる。

「最近のサプライチェーン被害は、これまで想定されていなかったような広がり方をしていると感じています。たとえば、アサヒGHDがサイバー攻撃を受けて業務が一時停止したことで、サントリーやキリンといった大手飲料メーカーも、予定していたキャンペーンを見送らざるを得なくなりました。これらの企業は本来、競合関係にありますが、共通の委託先が被害を受けたことで、競合同士が同時に影響を受けるという事態が起きたのです。このように、一社の被害が業界全体に波及する構造になってきており、もはや『自社だけ守ればよい』という時代ではありません。しかし、こうした被害は事前に予測するのが難しく、完全に備えるのは非常にハードルが高いと感じています。だからこそ、サプライチェーン全体でのリスク共有と連携した対策がますます重要になっていると思います」（成田氏）

上述のようにランサムウェアの被害を受けると、自社の業務が止まるだけでなく、取引先にも深刻な影響が及ぶ。社内システムに保存されていた取引先の情報が攻撃者に盗まれ、その情報が外部に流出する可能性も生まれてくる。

そのため、単なる情報漏洩にとどまらず、取引先の信用や業務にも直接的なダメージを与えることになるため、取引先から「自社の情報が漏れたことで損害を受けた」として、損害賠償を請求されるリスクも生じる。特に、契約書の中で情報管理の責任が明記されていた場合や、個人情報保護法などの法令に違反していると判断された場合には、法的な責任を問われる可能性が高くなる。

「ランサムウェアの被害は業務だけの問題ではなく、取引先との信頼関係や契約上の責任にも関わる重大なリスクを含んでいるのです。だからこそ、日頃から情報管理体制を整え、万が一の事態に備えておくことが重要です」（成田氏）

復旧の決め手はバックアップ

実際にサイバー攻撃に遭った場合、どのくらいの期間で復旧することができるのだろうか。復旧のスピードは、暗号化されたシステムやデータの範囲、被害の規模によって大きく左右される。

「ランサムウェアによって暗号化されたファイルは基本的に元に戻せません。そのため、バックアップから復元するか、あるいはシステムを一から作り直すしかない。早く復旧できるかどうかは、『バックアップを取っているか』、『それをどれだけ早く適用できるか』にかかっています。しかもバックアップといっても、単にデータだけでなく、システム全体のバックアップが必要です。たとえば名古屋港のケースでは、数日で復旧できており、非常に模範的な事例といえます。一方で、KADOKAWAのように数ヶ月も業務が停止したケースもあります」（成田氏）

つまり、復旧の度合いは、バックアップの可用性と実効性、システムの複雑性と相互接続の度合い、感染範囲の特定と再感染防止策の徹底に左右される。名古屋港の場合は、接続されているシステムの範囲が比較的限定されていたため、復旧が早く進んだと考えられる。

一方でKADOKAWAのケースでは、システムがあまりにも肥大化していたため、バックアップの復元が困難だったことから、最終的にはすべてを一から再構築することになった。こうしたケースは決して珍しくなく、特に大企業の場合、バックアップの適用よりも再構築の方が早いと判断されることも少なくない。アサヒGHDにようにシステムが非常に大規模になると、バックアップの適用自体が困難になる。

「企業のセキュリティ対策は、もはや自社だけの問題ではありません。現在求められているのは、サプライチェーン全体をどう守るかという視点です。サプライチェーンのどこかにセキュリティの脆弱性があれば、自社も被害を受ける可能性がある。だから全体としての防御力を高めることが不可欠なのです。特に、サプライチェーンの上位層に位置する企業は、関連企業に対してセキュリティガイドラインを策定・提示し、調達基準の中に『セキュリティ対策の有無』を明示する責任があります。また、中小企業であっても、海外企業への納入などグローバルな取引を行っている場合には、セキュリティ対策を講じなければ、将来的にサプライチェーンに参加できなくなる可能性も出てきます」（成田氏）

今後の対策としては、サプライチェーン全体のセキュリティガイドラインと調達要件の策定に加え、RDPやVPN、ネットワーク機器の脆弱性スキャンとパッチ適用の運用化が求められる。また、オフラインで改ざんできないようなバックアップを行うことと、サイバー攻撃などを想定した定期的なリストア訓練の実施も重要だ。さらに、フォレンジック調査（デジタル版の鑑識調査）や初動対応マニュアルの整備、経営層向けのサイバーレジリエンス訓練（サイバー危機への対応力を鍛える訓練）とBCP（事業継続計画）との統合も、今後のセキュリティ強化に欠かせない要素となる。 「アサヒGHDの事件は、セキュリティが単なるITの問題ではなく、経営そのものの問題であることを明確に示しました。企業経営においては、セキュリティを『コスト』としてではなく、『事業継続の前提』として捉える必要があります。サプライチェーン全体の防御を自社の防御と位置づけ、復旧能力、すなわちサイバーレジリエンスを競争力の源泉として捉えることが、今後の企業戦略において不可欠なのではないでしょうか」（成田氏）

The language of value in the modern enterprise has fundamentally changed. In boardrooms around the world, the conversation is dominated by new vocabulary: “AI-driven growth,” “speed to market,” “product innovation,” and the relentless pursuit of the “competitive advantage.” Yet, for many security leaders, the language they use to define their own value remains stuck in the past. It’s a dialect of blocked threats and patched vulnerabilities that feels increasingly disconnected from the core mission of the business.

This failure unequivocally stems from the models we use, rather than from a lack of intent. For decades, the return on a security investment was measured with the simple, defensive math of a cost center. This old model fails to capture the immense and often hidden value that a modern security posture contributes to the business. Now, we have a new economy — one where artificial intelligence (“AI”) is the primary engine of innovation and the cloud is the factory floor.

It’s time to reassess the calculus and explore a new economic framework, one that redefines security’s worth not by the incidents it prevents but by the business momentum it creates.

Calculating the true cost of disruption

For years, the quantifiable risk of a breach was a straightforward calculation of regulatory fines, customer notification costs, and credit monitoring services. These are still real costs, but they represent a fraction of the true financial impact in an AI-driven enterprise. The most significant danger isn’t isolated to loss of data. It’s the disruption of the intelligent systems that now form the central nervous system of the business.

Consider a global logistics company whose entire supply chain is orchestrated by an AI platform. A breach-like model poisoning compromises this system and acts as a catastrophic failure of the business itself. The true cost is the value of every delayed shipment, every broken supplier commitment, and the permanent loss of customer trust.

In this new reality, the most important metric becomes the cost of disruption avoidance. A modern, AI-powered security platform that can autonomously detect and neutralize a threat before it halts operations is both a defensive tool and a direct guarantor of revenue and business continuity.

Security as an accelerator — and an innovator

The second and, perhaps, most powerful shift in this new economic model is the reframing of security from a necessary defensive brake to a strategic accelerator. In the past, security was often seen as a gate, a checkpoint that slowed down development in the name of safety. Today, the opposite is true: A mature, unified security platform is one of the most effective tools for increasing the velocity of innovation.

Consider a financial services firm that’s racing to deploy a dozen new AI-powered financial models in a single year. In a traditional, fragmented security environment, each new model might require a six-week, manual security review — a process that would kill any hope of meeting their business goals. A modern, automated security platform that is woven into the development lifecycle can reduce that review process to a matter of days or even hours. It allows developers to innovate with confidence, knowing that security is an enabling partner, clearing the path for progress. This is a direct, quantifiable contribution to the company’s ability to compete and win.

Paying down the past: The value of a clean slate

Many organizations are silently being dragged down by a hidden liability: decades of accumulated “security debt.” This immense, unspoken risk is created by a patchwork of disconnected point products, inconsistent policies across different cloud environments, and the constant operational tax of managing dozens of disparate tools. It increases the attack surface and slows down the entire organization.

Moving to a single, unified security platform is akin to refinancing this debt. It provides a clean slate, a consistent and manageable foundation upon which to build the future. The value here is in the dramatic simplification of operations and the reduction of long-term risk, beyond just the savings on licensing costs. Consolidating from dozens of security tools to a single platform can dramatically cut an organization’s mean time to respond to a threat. It pays down an organization’s security debt and frees up its most valuable resources to focus on innovation.

Let’s speak a different language

These three concepts — the cost of disruption avoided, the velocity of innovation, and the reduction of security debt — form the pillars of a new, business-centric language for security leaders. They provide a holistic framework for calculating the true value of a modern security platform in a way that resonates with C-suite priorities.

Strategies, mandates, and action items for the modern CISO have evolved. Protecting the enterprise? Yes, of course. That is the first priority. But the new imperatives should also be to prove, in clear financial and operational terms, how security accelerates the business. Mastering this new economic language is the most essential step forward in this AI-driven world.

Curious about what else Helmut has to say? Check out his other articles on Perspectives.

現実には、膨大な計算資源を稼働させるための電力供給、高密度な半導体が発する熱を処理する冷却技術、そしてそれらを支える半導体と部材のサプライチェーンという、極めて物理的かつ重厚なインフラの問題が浮き彫りになりつつある。これらは地政学的なリスクや国家のエネルギー政策とも複雑に絡み合い、企業の戦略に無視できない影響を与え始めている。本稿では、AIデータセンターをめぐる電力、冷却、サプライチェーンという「物理的な壁」の実態を詳細に俯瞰し、この構造変化が日本企業のIT戦略や経営判断に対してどのような問いを突きつけているのかを深く掘り下げていく。

マクロ経済を揺るがす「AIの暴食」と電力インフラの限界点

かつてデータセンターの電力消費は、企業のコスト管理の一項目に過ぎなかったが、現在では国家レベルのエネルギー需給を左右するマクロ経済の主要論点へと変貌を遂げている。国際エネルギー機関（IEA）が発表した衝撃的な分析によれば、2024年の時点で世界のデータセンターは約415TWh（テラワット時）もの電力を消費しており、これは世界全体の電力需要の約1.5パーセントに相当する規模である。さらに深刻なのはその増加スピードであり、直近5年間を見てもデータセンターの電力消費は年率約12パーセントという驚異的なペースで増加し続けている。これは他の産業分野や家庭用需要の伸び率を遥かに凌駕する数値であり、デジタル化の進展とAIの普及がいかにエネルギー集約的なプロセスであるかを物語っている。

IEAの「Energy and AI」レポートにおける予測はさらに衝撃的である。AIによる計算需要が現在のペースで拡大し続ければ、2030年までにデータセンターの電力消費は現在の倍以上となる945TWh前後に達し、世界の電力需要の約3パーセント近くを占める可能性があると警鐘を鳴らしている。別の視点からの試算では、この消費規模は現在の日本一国が消費する総電力量に匹敵するとも言われており、たった一つの産業セクターが主要先進国レベルの電力を飲み込むという、前代未聞の事態が現実味を帯びているのである。また、欧州委員会も同様の危機感を抱いており、EU域内のデータセンター電力消費が2030年には2024年比で約1.6倍に達するというシナリオを提示している。その背景には、クラウドコンピューティングや動画ストリーミングの定着に加え、生成AIの学習および推論フェーズにおける膨大なワークロードが、将来の電力需要を牽引する最大のドライバーになるという明確な見通しがある。

このように、データセンターにおける電力消費の議論は、もはや一企業のIT予算の枠を超え、国家のエネルギー安全保障や脱炭素戦略と密接にリンクするようになっている。データセンターが集中する地域では、送配電網の容量不足である「系統制約」が深刻化しており、新規のデータセンター建設が電力供給の許可待ちで数年遅れるといった事態も世界各地で発生している。また、膨れ上がる電力需要は、各国が掲げるカーボンニュートラル目標との整合性を危うくする要因ともなり得る。再生可能エネルギーの供給が追いつかない場合、化石燃料による発電を維持せざるを得なくなるからだ。したがって、政府や規制当局は、データセンター誘致と電源開発、そして送電網の増強をセットで計画せざるを得ない状況に追い込まれており、AIインフラ論とは本質的に、限られた電力リソースを他の産業や家庭とどう配分するかという、社会的な調整問題へと発展しているのである。

高密度化する「熱」との戦いが招くファシリティのパラダイム転換

電力供給の問題と表裏一体の関係にあるのが、AIサーバーが発する猛烈な「熱」をいかに処理するかという冷却の課題である。GPU（画像処理半導体）を搭載したAIサーバーの高性能化は、計算能力の向上をもたらすと同時に、単位面積あたりの電力密度と排熱量を劇的に押し上げている。従来の企業の基幹システムやWebサーバーを収容する一般的なデータセンターでは、サーバーラック1本あたりの消費電力は5から10kW（キロワット）程度が標準的であり、部屋全体に冷気を循環させる従来型の空冷方式で十分に冷却が可能であった。しかし、生成AIの学習や推論に用いられるハイエンドのGPUサーバーをフル搭載したラックでは、1ラックあたりの消費電力が50kWを超え、場合によっては100kWに迫るケースも珍しくなくなっている。

これほどの高密度環境になると、空気による熱交換だけでは物理的に冷却が追いつかなくなる。空気を媒体とする冷却には熱容量の限界があり、ファンを高速回転させれば騒音が爆音となり、風量そのものがサーバー機器を物理的に振動させてしまうリスクすら生じるからだ。そこで注目されているのが、水や特殊な冷媒を用いる「液冷技術」である。調査会社TrendForceの分析によれば、AIデータセンターにおける液冷システムの採用率は、2024年時点の約14パーセントから、2025年には30パーセントを超えて急拡大すると予測されている。現状では世界全体のサーバー市場で見れば依然として空冷が主流ではあるものの、最先端のAI計算基盤においては、液冷への移行が不可逆的なトレンドとなりつつある。

液冷へのシフトは、単にエアコンを高性能なものに買い替えるといったレベルの話ではない。データセンターの設計思想そのものを根本から覆すパラダイム転換を意味するからだ。たとえば、チップに直接冷却プレートを密着させる「ダイレクトチップ冷却」や、サーバーごと絶縁性のある液体に沈める「浸漬冷却（イマージョンクーリング）」といった方式を導入するには、建物内の配管設備、床の耐荷重、電源供給のレイアウトなどをすべて見直す必要がある。従来型の5kWラックを前提とした既存のデータセンターに、後付けで100kW級のAIラックを大量に導入することは極めて困難であり、AI専用の新たな施設を建設するか、大規模な改修を行う必要に迫られる。また、冷却効率を示す指標であるPUE（Power Usage Effectiveness）の改善は、運用コストの削減だけでなく、環境負荷低減の観点からも至上命題となっている。AIインフラを語る際、どうしてもモデルのパラメータ数やGPUのスペックに目が奪われがちだが、それらを安定稼働させるための冷却インフラという物理層の制約こそが、今後のデータセンターの競争力を決定づける最大の要因になりつつあるのである。

偏在するサプライチェーンと地政学リスクが突きつける戦略的選択

AIインフラ構築のボトルネックは、電力や冷却といったファシリティ面だけにとどまらない。計算処理の中核を担うGPUやAIアクセラレータ、そしてデータの高速転送を支えるHBM（広帯域メモリ）など、半導体サプライチェーンの極端な偏在と集中もまた、深刻な制約要因となっている。NVIDIAの2024年度決算において、データセンター事業の売上が前年比217パーセント増という驚異的な伸びを記録したことは記憶に新しいが、これは世界中の資金と需要が、特定の企業の特定の製品に殺到したことを端的に示している。IoT Analyticsの市場レポートによれば、データセンター関連の設備・インフラ支出は2024年時点で約2900億ドル規模に達し、2030年には年間1兆ドル前後にまで膨張すると予測されているが、この巨額の投資マネーの多くは、限られたサプライヤーへと流れ込んでいるのが実情だ。

問題は、最先端のAI半導体を製造できるファウンドリや、HBMのような特殊メモリを量産できるメーカーが世界に数社しか存在しないという事実である。TSMCやSamsung、SK Hynixといった主要プレイヤーの生産能力はすでに逼迫しており、工場の新設やラインの増強には巨額の投資と数年単位の時間が必要となる。さらに、サーバー筐体、電源ユニット、冷却用のポンプや特殊配管といった周辺機器に至るまで、グローバルなサプライチェーンは複雑に絡み合っており、その結節点のどこか一つでも滞れば、全体の納期が遅延する構造になっている。ここに米中対立をはじめとする地政学的な緊張や、各国の輸出管理規制、データローカライゼーション（データの国内保存義務）といった政治的な要素が加わることで、AIインフラの調達は単なる購買業務ではなく、高度なリスク管理と国家戦略の読み解きが必要な領域へと変質している。

日本国内に目を転じても、事態は切迫している。2025年のジャパン・エナジー・サミットで共有された報告によれば、日本のデータセンター向け電力需要は総需要の約2パーセントを占めるに至っており、2030年には約5パーセントへ倍増する見込みである。特に東京圏には10GW（ギガワット）規模という巨大なデータセンター建設計画のパイプラインが存在し、これは地域のピーク電力需要の約17パーセントにも相当する。送電網の増強が追いつかなければ、計画の一部は実現不可能となるか、北海道や九州といった再生可能エネルギーのポテンシャルが高い地方への分散を余儀なくされるだろう。

こうした状況下で、企業のCIOやIT部門は難しい舵取りを迫られている。企画段階から電力消費と冷却コストを織り込んだリアリティのあるAI活用計画を策定すること、クラウド選定において単に機能や価格だけでなく、そのリージョンが依存する電源構成や地政学リスクを考慮に入れた「ポートフォリオ」を組むこと、そしてサプライチェーンの混乱を見越して調達戦略を多重化すること。これらが今後のIT戦略における必須の要件となる。AIインフラを巡る議論を「サーバー室の中」の技術論から引き剥がし、エネルギー政策や国際情勢という「サーバー室の外側」の現実と接続して捉え直す視座こそが、これからの経営層には求められているのである。

The morning of Monday, Oct 20, 2025, I went to my healthcare provider’s portal to pay a bill. This was my experience:

Upon calling my provider to pay over the phone, they were unable to take my payment as their internal systems were also down, leaving us customers hanging with no direction on how to proceed.

My healthcare provider’s SaaS was completely functional; however, their integrated payment vendor, which is reliant on AWS infrastructure, apparently has ineffective redundancies. So, the 10/20/2025 AWS outage resulted in a most unfortunate experience for any customer or employee hoping to utilize this important capability while hindering my healthcare organization from receiving revenue.

Who is to blame? AWS? The payment vendor? Ultimately, my healthcare provider is responsible for their customers’ (and employees’) inability to interact with their services. A cloud outage is not in the same acts-of-nature class as hurricanes, earthquakes, tornadoes, etc., but we do treat them as such and that is simply wrong because these outages can be mitigated.

This is a clear and far too common industry-wide epidemic: poor adoption and execution of cloud computing resilience, resulting in unreliable critical services to both customers and employees.

As reported directly by AWS’ Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region, a latent race condition in DynamoDB’s DNS management system led to an empty DNS record for the US-EAST regional endpoint, causing resolution failures affecting both customer and internal AWS service connections. This adversely affected the following services: Lambda, ECS, EKS, Fargate, Amazon Connect, STS, IAM Console Sign-In and Redshift.

On 10/29/2024, Microsoft 365 (m365.cloud.microsoft or portal.office.com) experienced an outage due to the rollout of an impacting code change. This affected Microsoft 365 admin center, Entra, Purview, Defender, Power Apps, Intune and add-ins & network connectivity in Outlook. This is all documented by Microsoft in Users may have experienced issues when accessing m365.cloud.microsoft or portal.office.com.

Both of these recent outages required vendors to halt automated processes and manually navigate recovery to bring affected systems back to an operational state. Let’s face it: Cloud providers are not magical and are subject to the same recovery patterns as any enterprise.

Outages are a reality of any system or platform and affect literally every organization. Hence:

Your cloud provider is a single point of failure!

Corporate infrastructure strategies vary from total dependence on provider vendors to actively taking ownership and architecting necessary redundancies for critical systems. When underlying provider outages occur, it is often a catalyst to revisit enterprise resilience strategy, even if you are not directly affected.

When examining an enterprise’s fault-tolerant architectures (which rarely even exist), it may be a good time to instead consider fault avoidance architectures. The latter kicks in when bad happens and the former actively monitors triggers to avoid bad.

This type of introspective examination is too often overlooked, as it is far easier for enterprises to fall into believing the many myths that govern their IT strategy and operations, especially when it comes to Cloud.

Unpacking the myths

Myth #1 – A single cloud provider reduces complexity

Vendors will place every kind of study and incentive in front of enterprise leadership to back the fallacy that locking into their platform is in the best interests of their company. Let’s be clear: It is always in the best interests of the vendor. This concept is then passed down from leadership to engineers who are encouraged to believe what their leadership tells them, and we get into a situation where thousands upon thousands of companies are under the control of a single vendor. Scary, right?

When it comes to multi-zonal resilience, app-cross-region resilience, blast-radius reduction, and resilient app patterns, there is additional complexity. Knowing that these approaches have dependencies on complex fine-tuned cloud infrastructures means there is no easy button.

Myth #2 – Cloud platform component defaults are generally a good starting point

Relying on easy-button best practices is what gets enterprises into trouble. The responsibility of an IT cloud infrastructure team is to work with solution architects and engineers to fine-tune their designs to optimize efficiencies, resilience and performance while controlling costs. Cloud vendor default configurations are necessary as they set a functional starting point, but they should never be trusted as a sound design. In fact, they can produce unnecessarily large loads on default regions when left unchecked. The AWS US-East-1 region is historically the most affected region when it comes to outages, and yet so many critical enterprise systems run exclusively in that region.

Vendor plug-and-play architectures must be scrutinized before going into production.

A responsible architecture governance practice should have a policy to avoid known outage-prone regions and single-point-of-failure configurations. These should be vetted in the architecture review board before ever going to production.

Myth #3 – My cloud provider/vendor will take care of me

Service level agreements (SLA) are paid out service credits tied to the cost of the affected service, not cash refunds. They generally start at 10% of service charges, never resulting losses. Your enterprise will literally get pennies back on dollars lost.

The July 2024 CloudStrike outage cost CloudStrike around $75M + $60M they paid out in service credits. This pales an order of magnitude when compared to just one customer, Delta Airlines, which lost $500M net. Parametrix Insurance’s detailed analysis estimates the total direct financial loss facing the US Fortune 500 companies is $5.4B. CloudStrike literally paid pennies on the dollar for their error, so an enterprise’s reliance on a vendor must be managed knowing this reality.

The 11/18/2025 Cloudflare outage, with its 20% hold on global web traffic, equally affected hundreds of millions of accounts, including major systems like X (Twitter), OpenAI/ChatGPT, Google’s Gemini, Perplexity AI, Spotify, Canva and even all three cloud providers. This heightens how a single vendor/platform dependency is a real threat to business continuity.

Enterprises must protect themselves because their vendors won’t.

Future purchase and contract negotiations should pivot toward SLA penalties that are based on enterprise losses over enterprise service costs. Unfortunately, this will drive service costs higher, but it builds in better financial protection when reliant on systems outside of your control.

Myth #4 – Multi-cloud is too expensive and too demanding

To mitigate the impact of regional cloud outages, enterprises that adopt multi-cloud architectures that prioritize resilience, portability, and failover orchestration find additional benefits when they are implemented with a mindset of fault avoidance and cost/performance optimization. This means multiple triggers govern where workloads run, resulting in optimal efficiencies.

This needs to be a priority effort backed by the C-Suite and requires a culture shift to succeed; hence, multi-cloud deployments are exceedingly rare. Still, those who have done this reap benefits well beyond resilience (e.g., large orgs like Walmart, Goldman Sachs, General Electric and BMW as well as SMBs like FirstDigital, Visma and Assorted Data Protection).

The NIST Cloud Federation Reference Architecture (NIST Special Publication 500-332) is a great document to establish a baseline grounding of these concepts.

• Active-active resilience is a pattern for mission-critical apps (e.g., financial trading, healthcare, e-commerce checkout). It maximizes resilience and availability, but at a higher cost due to duplicated infrastructure and complex synchronization. This pattern lends itself best toward fault avoidance with all the goodness of proactive efficiency and optimization triggers.
• Active-passive failover is a pattern where a primary cloud handles all traffic, and a secondary cloud is on standby. It provides disaster recovery without the full cost of active-active, but will introduce some downtime and requires a robust replication strategy. It clearly is only a fault-tolerant approach.
• Cloud bursting is a pattern where applications run primarily in one cloud but “burst” into another during demand spikes, providing elastic scalability without over-provisioning. It can also provide a good degree of fault tolerance.
• Workload partitioning (best-of-breed placement) is a pattern where different workloads are assigned to the cloud provider best suited for them. It greatly optimizes performance, compliance, and cost by leveraging provider strengths, but will not be fully fault-tolerant.

Myth #5 – Cloud has failed. It’s time to get out

This is a recurring theme each time there is a major cloud outage, often tied equally to a cost comparison between on-premises vs. cloud (yes, cloud almost always costs more). The reality is that while there is true value to cloud in the overall infrastructure strategy, there also is value in prioritizing an investment in infrastructure choices, leveraging sensible hybrid strategies. Two effective strategic architectures are based on edge and Kubernetes. Edge reduces blast radius, while Kubernetes provides portable resilience across providers. Both are recommended when aligned with workload architecture and operational maturity.

• Edge-integrated resilience extends workloads to the edge while maintaining synchronization with central clouds. Local edge nodes can continue operations even if cloud connectivity is disrupted, then reconcile state once reconnected. In addition to adding a moderate level of resiliency, it also benefits from ultra-low latency for real-time processing (e.g., IoT, manufacturing robotics, autonomous vehicles). This approach is often found in factory, retail store, and branch office use cases.
• Kubernetes-orchestrated resilience is a cloud-agnostic orchestration layer that can be leveraged locally and across multiple providers. In addition to a prominent level of resilience, this type of service mesh (e.g., Istio, Linkerd) adds traffic routing and failover capabilities that reduce vendor lock-in. Overall, it is a foundational enabler for multi-cloud, giving enterprises a consistent control plane across providers and on-premises.

Calls to action

There are two major enterprise IT leadership bias camps: Build and Buy. Both play a factor in every enterprise.

The reference architecture patterns shared above address Build bias workloads, which include integrations with Buy workloads.

Buy bias workloads are too often subject to vendor-defined SLAs discussed above, which are terribly limiting to 10-100% credits for charges based on the duration of an outage as penalties. Realistically, that really is not going to change; however, SaaS quality over the past 20 years has increased substantially:

This becomes the new bar and offers a great measure an enterprise can leverage for both themself and their vendors:

The 1-9 Challenge: Every SaaS vendor, integrator and internal enterprise solution should provide one “9” better than their underlying individual hosting platforms alone.

For example, when each cloud vendor provides a 99.9% SLA for a given service, leveraging an active-active multi-cloud architecture raises that SLA well beyond 99.99%.

Take control of your critical services first and leverage these patterns as a baseline for net-new initiatives moving forward, making high resilience your new norm.

Bottom line: the enterprise is always responsible for its own resiliency. It’s time to own this and take control!

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

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