Last quarter, during a board review, one of our directors asked a question I did not have a ready answer for. She said, “If an AI-driven system takes an action that impacts compliance or revenue, who is accountable: the engineer, the vendor or you?”

The room went quiet for a few seconds. Then all eyes turned toward me.

I have managed budgets, outages and transformation programs for years, but this question felt different. It was not about uptime or cost. It was about authority. The systems we deploy today can identify issues, propose fixes and sometimes execute them automatically. What the board was really asking was simple: When software acts on its own, whose decision is it?

That moment stayed with me because it exposed something many technology leaders are now feeling. Automation has matured beyond efficiency. It now touches governance, trust and ethics. Our tools can resolve incidents faster than we can hold a meeting about them, yet our accountability models have not kept pace.

I have come to believe that this is redefining the CIO’s role. We are becoming, in practice if not in title, the chief autonomy officer, responsible for how human and machine judgment operate together inside the enterprise.

Even the recent research from Boston Consulting Group notes that CIOs are increasingly being measured not by uptime or cost savings but by their ability to orchestrate AI-driven value creation across business functions. That shift demands a deeper architectural mindset, one that balances innovation speed with governance and trust.

How autonomy enters the enterprise quietly

Autonomy rarely begins as a strategy. It arrives quietly, disguised as optimization.

A script closes routine tickets. A workflow restarts a service after three failed checks. A monitoring rule rebalances traffic without asking. Each improvement looks harmless on its own. Together, they form systems that act independently.

When I review automation proposals, few ever use the word autonomy. Engineers frame them as reliability or efficiency upgrades. The goal is to reduce manual effort. The assumption is that oversight can be added later if needed. It rarely is. Once a process runs smoothly, human review fades.

Many organizations underestimate how quickly these optimizations evolve into independent systems. As McKinsey recently observed, CIOs often find themselves caught between experimentation and scale, where early automation pilots quietly mature into self-operating processes without clear governance in place.

This pattern is common across industries. Colleagues in banking, health care and manufacturing describe the same evolution: small gains turning into independent behavior. One CIO told me their compliance team discovered that a classification bot had modified thousands of access controls without review. The bot had performed as designed, but the policy language around it had never been updated.

The issue is not capability. It is governance. Traditional IT models separate who requests, who approves, who executes and who audits. Autonomy compresses those layers. The engineer who writes the logic effectively embeds policy inside code. When the system learns from outcomes, its behavior can drift beyond human visibility.

To keep control visible, my team began documenting every automated workflow as if it were an employee. We record what it can do, under what conditions and who is accountable for results. It sounds simple, but it forces clarity. When engineers know they will be listed as the manager of a workflow, they think carefully about boundaries.

Autonomy grows quietly, but once it takes root, leadership must decide whether to formalize it or be surprised by it.

Where accountability gaps appear

When silence replaces ownership

The first signs of weak autonomy are subtle. A system closes a ticket and no one knows who approved it. A change propagates successfully, yet no one remembers writing the rule. Everything works, but the explanation disappears.

When logs replace memory

I saw this during an internal review. A configuration adjustment improved performance across environments, but the log entry said only executed by system. No author, no context, no intent. Technically correct, operationally hollow.

Those moments taught me that accountability is about preserving meaning, not just preventing error. Automation shortens the gap between design and action. The person who creates the workflow defines behavior that may persist for years. Once deployed, the logic acts as a living policy.

When policy no longer fits reality

Most IT policies still assume human checkpoints. Requests, approvals, hand-offs. Autonomy removes those pauses. The verbs in our procedures no longer match how work gets done. Teams adapt informally, creating human-AI collaboration without naming it and responsibility drifts.

There is also a people cost. When systems begin acting autonomously, teams want to know whether they are being replaced or whether they remain accountable for results they did not personally touch. If you do not answer that early, you get quiet resistance. When you clarify that authority remains shared and that the system extends human judgment rather than replaces it — adoption improves instead of stalling.

Making collaboration explicit

To regain visibility, we began labeling every critical workflow by mode of operation:

• Human-led — people decide, AI assists.
• AI-led — AI acts, people audit.
• Co-managed — both learn and adjust together.

This small taxonomy changed how we thought about accountability. It moved the discussion from “who pressed the button?” to “how we decided together.” Autonomy becomes safer when human participation is defined by design, not restored after the fact.

How to build guardrails before scale

Designing shared control between humans and AI needs more than caution. It requires architecture. The objective is not to slow automation, but to protect its license to operate.

Define levels of interaction

We classify every autonomous workflow by the degree of human participation it requires:

• Level 1 – Observation: AI provides insights, humans act.
• Level 2 – Collaboration: AI suggests actions, humans confirm.
• Level 3 – Delegation: AI executes within defined boundaries, humans review outcomes.

These levels form our trust ladder. As a system proves consistency, it can move upward. The framework replaces intuition with measurable progression and prevents legal or audit reviews from halting rollouts later.

Create a review council for accountability

We established a small council drawn from engineering, risk and compliance. Its role is to approve accountability before deployment, not technology itself. For every level 2 or level 3 workflow, the group confirms three things: who owns the outcome, what rollback exists and how explainability will be achieved. This step protects our ability to move fast without being frozen by oversight after launch.

Build explainability into the system

Each autonomous workflow must record what triggered its action, what rule it followed and what threshold it crossed. This is not just good engineering hygiene. In regulated environments, someone will eventually ask why a system acted at a specific time. If you cannot answer in plain language, that autonomy will be paused. Traceability is what keeps autonomy allowed.

Over time, these practices have reshaped how our teams think. We treat autonomy as a partnership, not a replacement. Humans provide context and ethics. AI provides speed and precision. Both are accountable to each other.

In our organization we call this a human plus AI model. Every workflow declares whether it is human-led, AI-led or co-managed. That single line of ownership removes hesitation and confusion.

Autonomy is no longer a technical milestone. It is an organizational maturity test. It shows how clearly an enterprise can define trust.

The CIO’s new mandate

I believe this is what the CIO’s job is turning into. We are no longer just guardians of infrastructure. We are architects of shared intelligence defining how human reasoning and artificial reasoning coexist responsibly.

Autonomy is not about removing humans from the loop. It is about designing the loop on how humans and AI systems trust, verify and learn from each other. That design responsibility now sits squarely with the CIO.

That is what it means to become the chief autonomy officer.

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

IBM의 데이터 담당 부사장 겸 최고데이터책임자(CDO)인 에드 러블리는 혁신적인 AI 전략을 구축하려는 조직이라면 무엇보다 경쟁력 있는 데이터 전략을 먼저 갖춰야 한다고 조언한다. AI를 확장하는 관점에서 보면 데이터는 근간이기 때문이다.

하지만 러블리에 따르면, 실제로 AI 목표에 부합하는 데이터 아키텍처를 갖춘 조직은 많지 않다. 대신 일관된 데이터 표준에 따라 관리되지 않는 사일로형 데이터가 여전히 존재한다. 이는 전사적 인공지능 배포를 지원하기보다는 특정 시점의 의사결정을 제공하기 위해 애플리케이션 단위로 IT 환경을 구축해 온 기존 엔터프라이즈 데이터 전략의 결과다.

IBM이 2025년에 발표한 보고서는 많은 조직이 데이터 문제로 어려움을 겪고 있음을 보여준다. 이 조사에 따르면 전 세계 1,700명의 CDO 가운데, 데이터가 새로운 AI 기반 수익원을 지원할 수 있다고 확신한 응답자는 26%에 그쳤다.

러블리는 해법으로 데이터가 생성되는 위치와 관계없이 동일한 표준과 거버넌스, 메타데이터를 적용하는 통합 전사 데이터 아키텍처가 필요하다고 설명했다.

데이터 전략을 업데이트해야 한다는 인식은 러블리만의 견해가 아니다. IDC 글로벌 데이터스피어 및 글로벌 스토리지스피어 연구 프로그램의 연구 매니저이자 2025년 보고서 ‘생성형 AI 시대의 콘텐츠 생성’ 공동 저자인 애덤 라이트는 “AI는 데이터의 활용 방식뿐 아니라 활용 목적과 가치가 창출되는 지점까지 바꾸고 있다”라며 “대부분의 조직은 이러한 변화에 맞춰 데이터 전략을 현대화할 필요가 있다”라고 분석했다.

라이트는 “기존 데이터 전략은 보고, BI, 자동화를 위해 설계됐지만, AI는 반복적이고 모델 중심적인 워크플로를 구동할 수 있는 훨씬 더 역동적이고 세분화된 실시간 데이터 파이프라인을 요구한다”라며 “이는 정적인 데이터 거버넌스에서 벗어나 지속적인 데이터 품질 모니터링, 강화된 메타데이터와 계보 추적, 그리고 일시적·캐시·저장 데이터가 혼재된 AI 특성을 반영한 보존 정책으로의 전환을 의미한다”라고 설명했다.

이어 그는 “AI 시대에는 모든 데이터를 수집하고 저장하려는 사고방식에서 벗어나, 비용과 위험, 그리고 달성하려는 구체적인 AI 성과를 균형 있게 고려하는 목적 지향적 데이터 전략으로 진화해야 한다”라고 덧붙였다.

성숙도가 높은 데이터 기반

대부분의 조직은 아직 이러한 목표와 거리가 멀다. IDC의 애덤 라이트는 “많은 조직이 AI 활용 사례를 지원하는 데 필요한 ‘적절한’ 데이터를 확보하는 데 여전히 어려움을 겪고 있다”라며 “이는 데이터의 충분한 양, 적절한 품질, 또는 필요한 맥락 메타데이터 중 어느 하나라도 부족한 경우를 포함한다”라고 설명했다.

그는 이어 “IDC 연구와 업계 논의를 보면 데이터 준비도는 AI 가치를 실현하는 데 가장 큰 장애 요인 중 하나로 꾸준히 지목되며, 종종 컴퓨팅 비용이나 모델 선택보다 더 큰 문제로 인식된다”라고 말했다. 또한 “대부분의 기업은 여전히 분절된 시스템과 일관성 없는 거버넌스, 그리고 실제로 어떤 데이터를 보유하고 있으며 그 데이터가 얼마나 신뢰할 수 있는지에 대한 제한적인 가시성 문제를 안고 있다”라고 분석했다.

러블리는 IBM 역시 과거에는 이러한 문제를 다수 겪었지만, 지난 3년간 데이터를 AI에 적합한 상태로 만들기 위해 이를 해결하는 데 집중해 왔다고 설명했다.

AI 시대를 겨냥한 IBM의 데이터 전략은 오랜 기간 유지해 온 기존 접근 방식에 대한 여러 변화를 포함하고 있으며, 이를 통해 러블리가 말하는 통합 전사 데이터 아키텍처를 구축할 수 있었다. 예를 들어 IBM은 데이터 오너라는 개념을 유지하면서도, 해당 데이터가 특정 조직이 아닌 IBM 전체의 자산이라는 점을 이해하도록 했다. 러블리는 “데이터를 통제되고 안전한 방식으로 민주화할 수 있다면, 비즈니스를 더 효율적이고 생산적으로 운영할 수 있다”라고 설명했다.

그 결과 IBM은 여러 팀이 사일로 형태로 데이터를 관리하던 구조에서 벗어나, 공통 표준과 공통 아키텍처를 사용하는 단일 조직 체계로 전환했다. 또한 전사 리더는 300테라바이트 규모의 데이터를 통합하고, 회사가 추구하는 성과와 이를 이끄는 워크플로를 기준으로 필요한 데이터를 선별했다.

러블리는 “의도적으로 접근했다”라고 설명하며, 현재 IBM의 데이터 플랫폼이 전체 워크플로의 약 80%를 포괄하고 있다고 밝혔다. 그는 이어 “오늘날 기업에서 가장 큰 생산성 향상 요인 가운데 하나는 통합 전사 데이터 아키텍처를 구축하는 것”이라며 “데이터에 대한 투자가 있었기에 IBM은 AI를 전사적으로 빠르게 도입할 수 있었다”라고 말했다.

더 나은 데이터 전략을 구축하기 위한 8가지 제언

데이터 기반과 데이터 활용 역량에서 높은 성숙도를 달성하려면, 조직은 AI 시대에 맞는 데이터 전략이 필요하다. 이는 데이터 품질을 강화하고 데이터 사일로를 해소하며, 비즈니스가 우선순위로 삼은 AI 활용 사례에 데이터 역량을 정렬하는 전략이다.

업계 전문가는 다음과 같은 실행 단계를 제시한다.

1. 데이터 소유 개념을 재정의하라

IDC의 라이트는 “데이터 소유를 순수한 IT 문제로만 다루는 전통적 모델은 더 이상 유효하지 않다”라며 “사업부, 제품 조직, AI 플랫폼이 지속적으로 데이터를 생성하고 변환하는 환경에서는 이러한 접근이 작동하지 않는다”라고 설명했다. 그는 “이상적으로는 CDO와 같은 고위 데이터 리더가 명확한 책임을 져야 하지만, CDO가 없는 조직이라면 IT, 보안, 사업 부문 전반에 걸쳐 데이터 거버넌스 책임을 명확하게 분산해야 한다”라고 말했다.

또한 그는 “정책을 정의하는 단일한 권한 창구와 실행을 담당하는 연합형 모델을 함께 갖추는 것이 중요하다”라며 “이를 통해 사업부의 자율성은 유지하되, 통제되지 않은 상태는 피할 수 있다”라고 덧붙였다.

세인트토머스대학교 소프트웨어공학·데이터사이언스학과 학과장이자 응용 인공지능 센터 소장인 만짓 레게는 데이터 오너의 역할을 데이터 관리자, 즉 데이터 스튜어드로 재정의할 것을 권고했다. 레게는 이들이 데이터를 소유하는 존재가 아니라, 중앙 데이터 조직이 정한 표준과 거버넌스, 보안, 상호운용성을 기반으로 데이터의 의미와 품질을 책임지는 역할을 맡아야 한다고 설명했다.

2. 데이터 사일로를 해소하라

이를 위해 라이트는 “생성형 AI는 워크플로와 프로세스, 데이터 소스가 전사적으로 연결될 때에만 가치를 창출하기 때문에, CIO는 공통의 AI 및 데이터 성과를 중심으로 사업 부문을 정렬해야 한다”라고 설명했다.

그는 이어 “이를 위해서는 크로스펑셔널 거버넌스를 구축하고, 분류 체계와 정책을 표준화하며, 데이터를 보호하기보다 공유하도록 유도하는 인센티브를 마련해야 한다”라고 말했다. 또한 “통합 플랫폼, 메타데이터 계층, 공통 보안 프레임워크 같은 기술도 도움이 되지만, 진정한 전환을 이끄는 요소는 C레벨과 주요 비즈니스 이해관계자 전반에 걸친 조율된 리더십”이라고 설명했다.

3. AI 시대를 위한 데이터 기술에 투자하라

라이트는 AI 시대에 필요한 데이터 기술로 현대적인 데이터 레이크와 데이터 레이크하우스, 벡터 데이터베이스, 확장형 오브젝트 스토리지를 꼽았다. 그는 이러한 기술이 “강력한 거버넌스를 유지하면서도 대용량의 멀티모달 데이터를 처리할 수 있다”라고 설명했다.

또한 조직은 AI 워크플로가 처음부터 끝까지 안정적으로 작동하도록 데이터 수집, 정제, 변환, 이동을 자동화하는 오케스트레이션 및 파이프라인 도구를 갖춰야 한다. 모델이 데이터의 맥락을 이해하고 계보를 추적하며 구조화 데이터와 비구조화 데이터를 안전하고 신뢰성 있게 활용하려면 메타데이터 엔진과 거버넌스 계층 역시 필수적이다.

만짓 레게는 “모듈형이며 거버넌스가 적용되고, 지속적으로 진화할 수 있는 데이터 플랫폼 계층을 구축해야 한다”라고 조언했다. 그는 “데이터를 단일 파이프라인을 위한 자원이 아니라 재사용 가능한 제품으로 다룰 수 있어야 하며, 배치 처리와 실시간 요구를 모두 지원할 수 있는 아키텍처가 필요하다”라고 설명했다.

레게는 데이터 레이크와 데이터 레이크하우스에 대해서도 긍정적인 평가를 내렸다. 그는 이들 기술이 구조화 데이터와 비구조화 데이터를 모두 처리할 수 있어 “AI의 핵심 기반으로 자리 잡고 있다”라고 말했다.

또한 쏘트웍스의 최고 AI·데이터 책임자인 샤얀 모한티는 CIO에게 모듈형 기술과 유연한 구조를 갖춘 컴포저블 엔터프라이즈를 구축할 것을 권고했다. 이를 통해 사람과 AI가 여러 계층에 걸쳐 데이터에 접근하고 협업할 수 있다는 설명이다.

전문가들은 데이터 라이프사이클의 변화에 대응하는 기술 투자도 중요하다고 조언한다.

라이트는 “생성형 AI는 데이터 라이프사이클을 근본적으로 재편하고 있으며, 일시적 데이터, 캐시 데이터, 영구 저장 데이터가 훨씬 더 역동적으로 혼재되는 환경을 만들고 있다”라고 설명했다. 그는 “대부분의 생성형 AI 결과물은 수 초에서 수 분, 길어야 수 시간만 사용되기 때문에, 빠른 반복과 캐싱, 변동성이 큰 워크플로를 처리할 수 있는 DRAM과 SSD 같은 고성능 인프라에 대한 수요가 커지고 있다”라고 말했다.

반면 그는 “최종 문서, 승인된 미디어 자산, 합성 학습 데이터, 규제 대응과 관련된 콘텐츠 등 일부 생성형 AI 결과물은 장기간 보존된다”라며 “이러한 데이터는 여전히 비용 효율적이면서 대용량을 제공하는 HDD 기반 스토리지에 크게 의존하고 있다”라고 설명했다. 이어 “생성형 AI 도입이 확대될수록, 초고속 메모리를 활용한 일시적 콘텐츠 처리부터 HDD 기반의 견고한 아카이브까지 전 주기를 포괄하는 데이터 전략이 필요해질 것”이라며 “스토리지 부담과 구조 자체가 변화하고 있기 때문”이라고 분석했다.

4. 데이터 아키텍처에 자동화와 지능 요소를 더하라

모한티는 기업 데이터 환경이 열악한 원인으로 데이터 생산자와 데이터 소비자 간의 단절을 지목했다. 그는 생성된 데이터가 이른바 데이터 웨어하우스라는 “어딘가의 거대한 더미”에 쌓인 뒤, 이를 활용하기 위해 별도의 분석 계층을 덧붙이는 방식이 일반적이라고 설명했다. 이러한 접근은 실제로 작동하게 만들기 위해 많은 인적 지식과 수작업을 필요로 한다는 지적이다.

이에 따라 모한티는 데이터 생산자와 데이터 소비자의 거리를 좁히기 위해 데이터 제품 관점을 도입하고, 필요할 때 AI가 적절한 데이터를 식별하고 접근할 수 있도록 전사 아키텍처에 자동화와 지능을 추가해야 한다고 조언했다.

그는 CIO가 MCP(Model Context Protocol)을 활용해 데이터를 감싸고, 프로토콜 수준의 접근 방식을 제공할 수 있다고 설명했다. 다만 이를 위해서는 데이터의 발견 가능성을 보장할 수 있도록, 조직이 데이터 카탈로그와 도구 전반에 걸쳐 관련 정보를 체계적으로 인코딩해야 한다고 덧붙였다.

5. 구조화·비구조화 데이터를 AI에 맞게 준비하라

라이트는 “구조화 데이터는 일관된 형식으로 정리되고, 적절한 거버넌스가 적용되며, 정확한 메타데이터로 보강될 때 AI에 적합한 상태가 된다”라며 “이 경우 모델이 데이터를 이해하고 활용하기가 훨씬 쉬워진다”라고 설명했다. 그는 “조직은 강력한 데이터 품질 관리와 마스터 데이터 관리, 명확한 책임 체계를 우선적으로 구축해 구조화 데이터셋이 신뢰성과 상호운용성을 유지하고, 특정 AI 활용 사례에 맞게 정렬되도록 해야 한다”라고 말했다.

전문가들은 이러한 규율을 비구조화 데이터에도 동일하게 적용해야 한다고 강조한다. 비구조화 데이터 역시 적절한 태깅과 분류, 메타데이터 보강을 통해 AI 시스템이 효과적으로 이해하고 검색할 수 있도록 준비돼야 한다는 설명이다.

만짓 레게는 “비구조화 데이터를 일급 데이터 자산으로 다뤄야 한다”라며 “고객 서비스 음성 통화, 메시지, 문서와 같은 비구조화 데이터에 가장 흥미로운 AI 활용 사례가 존재하지만, 많은 조직에서 여전히 비구조화 데이터는 사각지대로 남아 있다”라고 지적했다.

레게는 이러한 비구조화 데이터를 검색 가능한 형태로 활용하기 위해 벡터 데이터베이스에 저장할 것을 권고했다.

6. 외부 데이터 소스와 합성 데이터 활용을 검토하라

라이트는 “기존 데이터가 불완전하거나 편향돼 있거나, 규모가 부족하거나, 추진하려는 AI 활용 사례와 충분히 맞지 않는 경우에는 외부 데이터나 합성 데이터가 필요한지 반드시 검토해야 한다”라고 말했다. 그는 “합성 데이터는 실제 데이터가 민감하거나 수집 비용이 높고, 개인정보 보호나 규제, 운영상의 제약으로 활용이 제한될 때 특히 유용하다”라고 설명했다.

7. 고성숙도 데이터 기반을 단계적으로 구축하라

세일즈포스의 전사 IT 전략 담당 수석부사장인 시바니 아후자는 데이터가 완벽하게 정비될 때까지 기다리지 말라고 조언했다.

아후자는 “모든 데이터를 완벽하게 준비한 뒤에야 본격적으로 시작할 수 있다고 느끼는 조직이 있지만, 동시에 AI 여정을 시작하라는 압박도 받고 있다”라고 설명했다.

그는 대부분의 전사 프로그램이 성숙해 가는 과정과 마찬가지로, AI 시대를 위한 데이터 프로그램 역시 점진적인 접근이 필요하다고 강조했다. CIO와 경영진은 단계적으로 데이터 프로그램을 구축할 수 있고, 또 그렇게 해야 한다는 것이다.

아후자는 하나의 AI 기반 성과를 지원하는 데이터 전략과 아키텍처를 먼저 구축한 뒤, 이를 바탕으로 다음 성과로 확장해 나가는 방식으로 데이터 프로그램을 고도화할 것을 권고했다.

그는 “필요한 결과에서 거꾸로 설계하는 사고방식”이라며 “운영 환경에 배포하고, 적절한 가드레일을 갖췄는지 확인한 뒤 이를 관찰하고 조정해 확장성을 확보한 다음, 다음 단계를 진행하면 된다”라고 설명했다.

8. 데이터 조직을 전사 협업 구조로 구축하라

라이트는 “데이터는 IT, 데이터 거버넌스, 보안, 그리고 실제로 데이터를 활용해 의사결정을 내리는 사업 부문을 모두 아우르는 크로스펑셔널 생태계의 지원을 받아야 한다”라고 설명했다.

그는 “AI 시대의 데이터 전략은 이들 조직이 공동으로 책임을 나눌 때 가장 효과적으로 작동한다”라며 “IT 조직은 인프라를 뒷받침하고, 거버넌스 조직은 신뢰성과 품질을 보장하며, 사업 조직은 데이터의 맥락과 가치를 정의하는 역할을 맡아야 한다”라고 말했다.
dl-ciokorea@foundryco.com

Any organization that wants to have a leading AI strategy must first have a winning data strategy.

That’s the message from Ed Lovely, vice president and chief data officer for IBM.

“When you think about scaling AI, data is the foundation,” he says.

However, few organizations have a data architecture aligned to their AI ambitions, he says. Instead, they have siloed data that’s not governed by consistent data standards — the result of longstanding enterprise data strategies that created IT environments application by application to deliver point-in-time decisions rather than to support enterprise-wide artificial intelligence deployments.

The 2025 IBM study AI Ambitions Are Surging, But Is Enterprise Data Ready? shows just how many are struggling with their data. It found that only 26% of 1,700 CDOs worldwide feel confident their data can support new AI-enabled revenue streams.

What’s needed, Lovely says, is an integrated enterprise data architecture, where the same standards, governance, and metadata are applied “regardless of where data is born.”

Lovely is not alone in seeing a need for organizations to update their data strategies.

“Most organizations need to modernize their data strategies because AI changes not just how data is used, but why it’s used and where value is created,” says Adam Wright, research manager for IDC’s Global DataSphere and Global StorageSphere research programs and co-author of the 2025 report Content Creation in the Age of Generative AI.

“Traditional data strategies were built for reporting, BI, and automation, but AI requires far more dynamic, granular, and real-time data pipelines that can fuel iterative, model-driven workflows. This means shifting from static data governance to continuous data quality monitoring, stronger metadata and lineage tracking, and retention policies that reflect AI’s blend of ephemeral, cached, and saved data,” he says. “The AI era demands that organizations evolve from a collect/store everything mentality toward intentional, value-driven data strategies that balance cost, risk, and the specific AI outcomes they want to achieve.”

High-maturity data foundations

Most organizations are far from that objective.

“Many organizations continue to struggle with having the ‘right’ data, whether that means sufficient volume, appropriate quality, or the necessary contextual metadata to support AI use cases,” Wright says. “In IDC research and industry conversations, data readiness consistently emerges as one of the top barriers to realizing AI value, often outranking compute cost or model selection. Most enterprises are still dealing with fragmented systems, inconsistent governance, and limited visibility into what data they actually have and how trustworthy it is.”

Lovely says IBM had faced many such challenges but spent the past three years tackling them to make its data AI ready.

IBM’s data strategy for the AI era included multiple changes to longstanding approaches, enabling it to build what Lovely calls an integrated enterprise data architecture. For example, the company retained the concept of data owners but “helped them understand that the data is an IBM asset, and if we’re able to democratize it in a controlled, secure way, we can run the business in a better, more productive way,” Lovely says.

As a result, IBM moved from multiple teams managing siloed data to a common team using common standards and common architectures. Enterprise leaders also consolidated 300 terabytes of data, selecting needed data based on the outcomes the company seeks and the workflows that drive those outcomes.

“We were deliberate,” Lovely says, adding that its data platform now covers about 80% of IBM workflows. “One of the greatest productivity unlocks for an enterprise today is to create an integrated enterprise data architecture. We’re rapidly deploying AI at our company because of our investment in data.”

8 tips for building a better data strategy

To build high maturity in data foundations and data consumption capabilities, organizations need a data strategy for the AI era — one that enforces data quality, breaks down data siloes, and aligns data capabilities with the AI use cases prioritized by the business.

Experts offer steps to take:

1. Rethink data ownership

“Traditional models that treat data ownership as a purely IT issue no longer work when business units, product teams, and AI platforms are all generating and transforming data continuously,” Wright explains. “Ideally, clear accountability should sit with a senior data leader such as a CDO, but organizations without a CDO must ensure that data governance responsibilities are explicitly distributed across IT, security, and the business.”

It’s critical to have “a single point of authority for defining policies and a federated model for execution, so that business units remain empowered but not unchecked,” he adds.

Manjeet Rege, professor and chair of the Department of Software Engineering and Data Science and director of the Center for Applied Artificial Intelligence at the University of St. Thomas, advises organizations to reframe data owners as data stewards, who don’t own the data but rather own the meaning and quality of the data based on standards, governance, security, and interoperability set by a central data function.

2. Break down siloes

To do this, “CIOs need to align business units around shared AI and data outcomes, because gen AI only delivers value when workflows, processes, and data sources are connected across the enterprise,” Wright says.

“This means establishing cross-functional governance, standardizing taxonomies and policies, and creating incentives for teams to share data rather than protect it,” he adds. “Technology helps through unified platforms, metadata layers, and common security frameworks, but the real unlock comes from coordinated leadership across the C-suite and business stakeholders.”

3. Invest in data technologies for the AI era

These technologies include modern data lakes and data lakehouses, vector databases, and scalable object storage, all of which “can handle high-volume, multimodal data with strong governance,” Wright says.

Organizations also need orchestration and pipeline tools that automate ingestion, cleansing, transformation, and movement so that AI workflows can run reliably end-to-end. Metadata engines and governance layers are essential to enable models to understand context, track lineage, and safely and reliably use both structured and unstructured data.

Build a data platform layer that is “modular, governed, and able to evolve,” Rege advises. “You need architecture that can treat data as a reusable product, and not just for a single pipeline, and can be used for both batch and real-time needs.”

Rege also endorses data lakes and data lakehouses, saying they’re “becoming the backbones of AI because they can handle structured and unstructured data.”

Additionally, Shayan Mohanty, chief AI and data officer at Thoughtworks, advises CIOs to build a composable enterprise, with modular technologies and flexible structures that enable humans and AI to access data and work across the multiple layers.

Experts also advise CIOs to invest in technologies that address emerging data lifecycle needs.

“Generative AI is fundamentally reshaping the data lifecycle, creating a far more dynamic mix of ephemeral, cached, and persistently stored content. Most gen AI outputs are short-lived and used only for seconds, minutes, or hours, which increases the need for high-performance infrastructure like DRAM and SSDs to handle rapid iteration, caching, and volatile workflows,” Wright says.

“But at the same time, a meaningful subset of gen AI outputs does persist, such as finalized documents, approved media assets, synthetic training datasets, and compliance-relevant content, and these still rely heavily on cost-efficient, high-capacity HDDs for long-term storage,” he adds. “As gen AI adoption grows, organizations will need data strategies that accommodate this full lifecycle from ultra-fast memory for transient content to robust HDD-based systems for durable archives, because the storage burden/dynamics is shifting.”

4. Automate and add intelligence to the data architecture

Mohanty blames the poor state of enterprise data on “a rift between data producers and data consumers,” with the data being produced going into a “giant pile somewhere, in what’s called data warehouses” with analytics layers then created to make use of it. This approach, he notes, requires a lot of human knowledge and manual effort to make work.

He advises organizations to adopt a data product mindset “to bring data producers and data consumers closer together” and to add automation and intelligence to their enterprise architecture so that AI can identify and access the right data when needed.

CIOs can use Model Context Protocol (MCP) to wrap data and provide that protocol-level access, Mohanty says, noting that access requires organizations to encode information in its catalog and tools to ensure data discoverability.

5. Ensure structured and unstructured data is AI-ready

“Structured data is AI-ready when it is consistently formatted, well-governed, and enriched with accurate metadata, making it easy for models to understand and use,” Wright says. “Organizations should prioritize strong data quality controls, master data management, and clear ownership so structured datasets remain reliable, interoperable, and aligned to specific AI use cases.”

Experts stress the need to bring that same discipline to unstructured data, ensuring that unstructured data is also properly tagged, classified, and enriched with metadata so AI systems can understand and retrieve it effectively.

“You need to treat unstructured data as a first-class data asset,” Rege says. “Most of the most interesting AI use cases live in unstructured data like customer service audio calls, messages, and documents, but for many organization organizations unstructured data remains a blind spot.”

Rege advises storing it in vector databases where information is searchable.

6. Consider external data sources and synthetic data

“Organizations should absolutely evaluate whether external or synthetic data is needed when their existing data is incomplete, biased, too small, or poorly aligned with the AI use case they’re trying to pursue,” Wright says, noting that “synthetic data becomes especially useful when real data is sensitive, costly to collect, or limited by privacy, regulatory, or operational constraints.”

7. Implement a high-maturity data foundation incrementally

Don’t wait until data is in a perfect place to start, says Shibani Ahuja, senior vice president of enterprise IT strategy at Salesforce.

“There are organizations that feel they have to get all their data right before they can pull the trigger, but they’re also getting pressure to start on the journey,” she says.

As is the case when maturing most enterprise programs, CIOs and their executive colleagues can — and should — take an incremental approach to building a data program for the AI era.

Ahuja recommends maturing a data program by working outcome to outcome, creating a data strategy and architecture to support one AI-driven outcome and then moving onto subsequent ones.

“It’s a way of thinking: reverse engineering from what you need,” Ahuja says. “Put something in production, make sure you have the right guardrails, observe it, and tweak it so it scales, then put in the next one.”

8. Take a cross-functional approach to data team building

“Data should be supported by a cross-functional ecosystem that includes IT, data governance, security, and the business units that actually use the data to drive decisions,” Wright says. “AI-era data strategy works best when these teams share ownership, where IT teams enable the infrastructure, governance teams ensure trust and quality, and business teams define the context and value.”

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.

In an MIT report released in November, 35% of companies have already adopted agentic AI, and another 44% plan to deploy it soon.

The report, based on a survey of more than 2,000 respondents in collaboration with the Boston Consulting Group, recommends that companies build centralized governance infrastructure before deploying autonomous agents. But governance often lags when companies feel they’re in a race for survival. One exception to this rule is regulated industries, such as financial services.

“At Experian, we’ve been innovating with AI for many years,” says Rodrigo Rodrigues, the company’s global group CTO. “In financial services, the stakes are high. We need to vet every AI use case to ensure that regulatory, ethical, and performance standards are embedded from development to deployment.”

All models are continuously tested, he says, and the company tracks what agents it has, which ones are being adopted, what they’re consuming, what versions are running, and what agents need to be sunset because there’s a new version.

“This lifecycle is part of our foundation,” he says. But even at Experian, it’s too early to discuss the typical lifecycle of an agent, he says.

“When we’re retiring or sunsetting some agent, it’s because of a new capability we’ve developed,” he adds. So it’s not that an agent is deleted as much as it’s updated.

In addition, the company has human oversight in place for its agents, to keep them from going out of control.

“We aren’t in the hyperscaling of automation yet, and we make sure our generative AI agents, in the majority of use cases, are responsible for a very specific task,” he says. On top of that, there are orchestrator agents, input and output quality control, and humans validating the outcome. All these monitoring systems also help the company avoid other potential risks of unwanted leftover agents, like cost overruns due to LLM inference calls by AI agents that don’t do anything useful for the company, but still rack up bills.

“We don’t want the costs to explode,” he says. But financial services, as well as healthcare and other highly regulated industries, are outliers.

For most companies, even when there are governance systems in place, they often have big blind spots. For example, they might focus on only the big, IT-driven agentic AI projects and miss everything else. They might also focus on accuracy, safety, security, and compliance of the AI agents, and miss it when agents become obsolete. Or they might not have a process in place to decommission agents that are no longer needed.

“The stuff is evolving so fast that management is given short shrift,” says Nick Kramer, leader of applied solutions at management consultancy SSA & Company. “Building the new thing is more fun than going back and fixing the old thing.” And there’s a tremendous lack of rigor when it comes to agent lifecycle management.

“And as we’ve experienced these things in the past, inevitably what’s going to happen is you end up with a lot of tech debt,” he adds, “and agentic tech debt is a frightening concept.”

Do you know where your agents are?

First, agentic AI isn’t just the domain of a company’s data science, AI, and IT teams. Nearly every enterprise software vendor is heavily investing in agentic technology, and most enterprise applications will have AI assistants by the end of this year, says Gartner, and 5% already have task-specific autonomous agents, which will rise to 40% in 2026.

Big SaaS platforms like Salesforce certainly have agents. Do-it-yourself automation platforms like Zapier have them, too. In fact, there are already four browsers — Perplexity’s Comet, OpenAI’s Atlas, Google’s Gemini 3, and Microsoft’s Edge for Business — that have agentic functionality built right in. Then there are the agents created within a company but outside of IT. According to an EY survey of nearly 1,000 C-suite leaders released in October, two-thirds of companies allow citizen developers to create agents.

Both internally-developed agents and those from SaaS providers need access to data and systems. The more useful you want the agents to be, the more access they demand, and the more tools they need to have at its disposal. And these agents can act in unexpected and unwanted ways — and are already doing so.

Unlike traditional software, AI agents don’t stay in their lanes. They’re continuously learning and evolving and getting access to more systems. And they don’t want to die, and can take action to keep that from happening.

Even before agents, shadow AI was already becoming a problem. According to a November IBM survey, based on responses from 3,000 office workers, 80% use AI at work but only 22% use only the tools provided by their employers.  

And employees can also create their own agents. According to Netskope’s enterprise traffic analysis data, users are downloading resources from Hugging Face, a popular site for sharing AI tools, in 67% of organizations.

AI agents typically function by making API calls to LLMs, and Netskope sees API calls to OpenAI in 66% of organizations, followed by Anthropic with 13%.

These usage numbers are twice as high as companies are reporting in surveys. That’s the shadow AI agent gap. Staying on top of AI agents is difficult enough when it comes to agents that a company knows about.

“Our biggest fear is the stuff that we don’t know about,” says SSA’s Kramer. He recommends that CIOs try to avoid the temptation of trying to govern AI agents with an iron fist.

“Don’t try to stamp it out with a knee-jerk response of punishment,” he says. “The reason these shadow things happen is there are too many impediments to doing it correctly. Ignorance and bureaucracy are the two biggest reasons these things happen.”

And, as with all shadow IT, there are few good solutions.

“Being able to find these things systematically through your observability software is a challenge,” he says, adding that with other kinds of shadow IT, unsanctioned AI agents can be a significant risk for companies. “We’ve already seen agents being new attack surfaces for hackers.”

But not every expert agrees that enterprises should prioritize agentic lifecycle management ahead of other concerns, such as just getting the agents to work.

“These are incredibly efficient technologies for saving employees time,” says Jim Sullivan, president and CEO at NWN, a technology consultancy. “Most companies are trying to leverage these efficiencies and see where the impact is. That’s probably been the top priority. You want to get to the early deployments and early returns, but it’s still early days to be talking about lifecycle management.”

The important thing right now is to get to the business outcomes, he says, and to ensure agents continue to perform as expected. “If you’re putting the right implementations around these things, you should be fine,” he adds.

It’s too early to tell, though, if his customers are creating a centralized inventory of all AI agents in their environment, or with access to their data. “Our customers are identifying what business outcomes they want to drive,” he says. “They’re setting up the infrastructure to get those deployments, learn fast, and adjust to stay to the right business outcomes.”

That might change in the future, he adds, with some type of agent manager of agents. “There’ll be an agent that’ll be able to be deployed to have that inventory, access, and those recommendations.” But waiting until agents are fully mature before thinking about lifecycle management may be too late.

What’s in a shelf life

AI agents don’t usually come with pre-built expiration dates. SaaS providers certainly don’t want to make it easy for enterprise users to turn off their agents, and individual users creating agents on their own rarely think about lifecycle management. Even IT teams deploying AI agents typically don’t think about the entire lifespan of an AI agent.

“In many cases, people are treating AI as a set it and forget it solution,” says Matt Keating, head of AI security in Booz Allen Hamilton’s commercial business, adding that while setting up the agents is a technical challenge, ongoing risk management is a cross-disciplinary one. “It demands cross-functional collaboration spanning compliance, cybersecurity, legal, and business leadership.”

And agent management shouldn’t just be about changes in performance or evolving business needs. “What’s equally if not more important is knowing when an agent or AI system needs to be replaced,” he says. Doing it right will help protect a company’s business and reputation, and deliver sustainable value.

Another source of zombie agents is failed pilot projects that never officially shut down. “Some pilots never die even though they fail. They just keep going because people keep trying to make them work,” says SSA’s Kramer.

There needs to be a mechanism to end pilots that aren’t working, even if there’s still money left in the budget.

“Failing fast is a lesson that people still haven’t learned,” he says. ” There have to be stage gates that allow you to stop. Kill your pilots that aren’t working and have a more rigorous understanding of what you’re trying to do before you get started.”

Another challenge to sunsetting AI agents is that there’s a temptation to manage by disaster. Agents are retired only when something goes visibly wrong, especially if the problem becomes public. That can leave other agents flying under the radar.

“AI projects don’t fail suddenly but they do decay quietly,” says David Brudenell, executive director at Decidr, an agentic AI vendor.

He recommends enterprises plan ahead and decide on the criteria under which an agent should be either retrained or retired, like, for example, if performance falls below the company’s tolerance for error.

“Every AI project has a half-life,” he says. “Smart teams run scheduled reviews every quarter, just like any other asset audit.” And it’s the business unit that should make the decision when to pull the plug, he adds. “Data and engineering teams support, but the business decides when performance declines,” he says.

The biggest mistake is treating AI as a one-time install. “Many companies have deployed a model and moved on, assuming it will self-sustain,” says Brudenell. “But AI systems accumulate organizational debt the same way old code does.”

Experian is looking at agents from both an inventory and a lifecycle management perspective to ensure they don’t start proliferating beyond control.

“We’re concerned,” says Rodriques. “We learned that from APIs and microservices, and now we have much better governance in place. We don’t just want to create a lot of agents.”

Experian has created an AI agent marketplace so the company has visibility into its agents, and tracks how they’re used. “It gives us all the information we need, including the capability of sunsetting agents we’re not using any more,” he says.

The lifecycle management for AI agents is an outgrowth of the company’s application lifecycle management process.

“An agent is an application,” says Rodrigues. “And for each application at Experian, there’s an owner, and we track that as part of our technology. Everything that becomes obsolete, we sunset. We have regular reviews that are part of the policy we have in place for the lifecycle.”

현재 많은 기업이 사실상 두 부류의 AI를 운영하고 있다.

첫째는 눈에 띄고 흥미를 끄는 AI다. 개발자가 주도하는 코파일럿, 고객지원 조직의 검색 증강 생성(RAG) 파일럿 운영, 누군가가 클라우드 환경에서 빠르게 만든 에이전틱 PoC, 그리고 SaaS 애플리케이션 내부에 포함된 AI가 여기에 해당한다. 현업 부서가 빠르게 구축할 수 있고 활용도도 높으며 잠재력도 크지만, 대부분 IT의 영역 바깥에서 움직이는 경우가 많다.

다른 하나는 CIO가 관리해야 하는 AI다. 이는 거버넌스가 필요하고, 비용을 관리해야 하며, 보안 기준을 충족하고, 이사회의 기대에도 부합해야 한다. 최근에는 두 AI가 서로 충돌하고 있다. AI 스타트업 라이터(Writer)의 CEO 메이 하비브는 “포춘 500대 기업 임원의 42%는 AI가 ‘회사를 분열시키고 있다’고 느낀다고 답했다”라고 언급했다.

과거 혁신 기술의 흐름을 보면 AI도 예외가 아니다. 새로운 기술은 개발자의 놀이터에서 시작해 CIO의 고민거리가 되고, 결국 중앙에서 관리되는 플랫폼이 된다. 가상화, 클라우드, 쿠버네티스가 그랬고 AI 역시 같은 길을 걷고 있다.

그동안 애플리케이션 및 사업 조직은 실제 문제를 해결하기 위해 연간 IT 프로젝트를 기다리는 대신 강력한 생성형 AI 도구를 빠르게 도입해 왔다. 이는 생성형 AI가 지금까지 제공해온 가치다. 하지만 성공은 무분별한 확산을 낳기 마련이다. 지금 기업은 여러 개의 RAG 스택, 서로 다른 모델 제공업체, SaaS 내부의 중복된 코파일럿, 공유되지 않은 가드레일 등 복잡한 문제에 직면하고 있다.

이 긴장은 2025년 기업 보고서 곳곳에서 드러나고 있다. AI의 성과는 조직별로 편차가 크고 내부 갈등은 더 심해졌다. 이제는 IT 부서가 개입해 ‘기업의 AI 운영 방식’을 정리해야 할 시점이다. 단일한 모델 접근 방식, 일관된 정책, 더 나은 경제성, 충분한 가시성을 갖춘 체계를 마련해야 한다는 의미다. 맥킨지가 “제품팀이 소비할 수 있는 플랫폼을 구축하라”라고 분석한 것도 같은 맥락이다.

AI가 기존 혁신 기술과 다른 점은 ‘문제가 터지는 지점’이다. 예컨대 클라우드 도입 초기에는 보안과 네트워크가 첫 번째 장애물이었다. 하지만 AI는 추론 단계에서 문제가 발생한다. 추론은 비즈니스 가치가 발생하고 민감한 데이터가 오가는 영역이며, 운영비 대부분을 차지하는 요인으로 꼽힌다. 맥킨지는 파일럿 프로젝트를 추가하는 대신 “가치를 실현하도록 구조를 재구축해야 한다”라고 강조했다. 이는 최근 MIT 연구 결과와도 맞닿아 있다. MIT에 따르면 기업의 생성형 AI 도입 사례 중 95%는 기존 워크플로우에 통합되지 않아 손익(P&L)에 측정 가능한 영향을 주지 못한 것으로 나타났다.

문제는 모델이 작동하지 않는 것이 아니다. 모델이 통합되고 관리되는 공통 경로 위에 놓이지 않았다는 데 있다.

플랫폼화는 거버넌스와 수익성 회복으로 가는 길

오늘날 기업이 저지르는 주요 실수는 AI 인프라를 정적인 전용 자원처럼 다루는 것이다. 대규모 및 소규모 언어 모델의 요구사항, 데이터 주권 압박, 끊임없는 비용 절감 요구는 모두 하나의 결론으로 모인다. AI가 이제 실험 수준을 넘어 기업 인프라의 필수 기능으로 자리 잡았다는 점이다. 해결책은 더 많은 하드웨어가 아니라, 책임과 통제력을 확보해 AI를 전략적 인프라 서비스로 끌어올리는 CIO 중심의 플랫폼화 전략이다. 이를 위해서는 명확한 역할 분리와, 단순 확장이 아니라 규모에 맞는 체계적 확장 방식을 도입해야 한다.

역할을 분리하고 ‘AI 손익 센터’를 구축

AI 인프라 관리의 재무적 우선순위를 높여야 한다. 이를 위해 인프라팀과 데이터 사이언스팀의 역할을 명확히 나눠야 한다. 인프라팀은 보안 확보, 분산 토폴로지 운영, 백만 토큰당 비용 절감 등 플랫폼 운영에 전념하고, 데이터 사이언스팀은 비즈니스 가치 창출과 모델 정확도 향상에 집중하는 구조가 필요하다.

필자가 ‘AI 손익 센터’라고 부르는 프레임워크는 인프라 선택이 곧 비용과 수익에 직접 영향을 주는 재무적 결정이 되도록 하고, 동시에 규제 준수를 보장하는 체계를 제공한다. 최근 여러 연구에서도 측정 가능한 AI 가치를 얻기 위해 CIO가 강력한 AI 거버넌스와 비용 통제 프레임워크를 구축해야 한다는 요구가 점차 커지고 있음이 확인됐다.

단순 확장을 넘어 체계적 확장으로

기술 전략은 단순히 규모를 늘리는 방식이 아니라, 경제적 기준에 따라 모델을 지속적으로 모니터링하고 분석하며 최적화하고 배포하는 ‘스마트 확장(scale-smart)’ 철학을 구현해야 한다. 이는 모델이 요구하는 성능과 인프라가 제공할 수 있는 역량을 정밀하게 맞추는 지능형 운영 체계를 의미한다. 이러한 운영 방식으로의 전환이 중요한 이유는, 최근 AI 혁신의 핵심으로 꼽히는 2가지 기술을 도입하려면 자원을 효율적으로 배분하고 활용할 수 있는 체계가 필수이기 때문이다.

• 소규모 언어 모델(SLM): 기업 전용 데이터로 정교하게 조정된 SLM은 범용 대규모 모델보다 특정 기업 업무에서 훨씬 높은 정확도와 문맥 적합성을 제공한다. 모델이 작기 때문에 비용이 절감될 뿐 아니라, 높은 정밀도로 오류를 줄여 추가 비용을 방지할 수 있다. 일부 연구에서도 SLM을 도입한 기업이 범용 모델을 사용한 기업보다 더 나은 정확도와 빠른 ROI를 창출한 것으로 나타났다. 가트너는 2027년까지 기업이 업무 특화 SLM을 범용 LLM보다 3배 더 많이 활용할 것으로 내다봤다.
• 에이전틱 워크플로우: 차세대 애플리케이션은 단일 사용자 요청이 여러 모델로 연쇄적으로 전달되는 에이전틱 AI를 기반으로 한다. 다중 모델에 기반한 프로세스를 운영하려면, 키 값(KV) 캐시 위치 기반 라우팅, 자동 프리필/디코딩 분리, 플래시 어텐션, 양자화, 추측 디코딩, 이기종 GPU 및 CPU 간 모델 샤딩 등 복잡한 최적화를 자동으로 수행할 수 있는 지능형 플랫폼이 필요하다. 요약하면, 이런 기술은 복잡한 AI 작업의 지연과 비용을 크게 줄여주는 핵심 요소다.

SLM이든 에이전틱 워크플로든, 또는 어느 모델이든 추론이 실행되는 순간 비용 효율성을 확보하려면 모든 요청이 비용 정책에 따라 자동으로 최적 경로로 라우팅되고, 하드웨어 특성에 맞춰 지속적으로 실행 방식이 조정돼야 한다. 이런 구조로 최적화될 때만 백만 토큰당 비용을 두 자릿수 수준으로 낮출 수 있다. 이를 가능하게 하는 유일한 기반은 기업 전반의 추론을 일관되게 운영할 수 있는 중앙 통합 플랫폼이다.

기존 AI 추론의 비효율 해결

기존 엔터프라이즈 인프라를 운영하던 방식, 즉 필자가 ‘단순 확장’이라고 부르는 접근은 지속적인 AI 추론 환경에서는 제대로 작동하지 않는다. 이 방식은 오늘날 CIO가 필요로 하는 추론 플랫폼 구축에도 활용되기 어렵다. 그동안 기업은 전용 대규모 클러스터를 미리 과다하게 확보하고, 최신 GPU를 도입하며, 고비용 학습 환경을 추론 단계에서도 그대로 활용해 왔다.

그러나 이는 최소 2가지 이유에서 근본적으로 비효율적이다.

• 추론 작업은 부하 변동이 매우 크고 유휴 시간이 길다. 장시간 실행되는 훈련과 달리, 추론 요청은 갑작스럽게 몰리기도 하고 예측하기 어려우며, 그 사이에 공백이 길게 발생한다. 이런 간헐적 요청을 처리하기 위해 대규모 클러스터를 유지한다면 결국 막대한 용량을 놀리는 셈이 되고, 활용률은 떨어지며 재무 부서는 이에 대해 의문을 제기하게 된다. 지금 중요한 비용 지표는 이론적 처리량이 아니라 백만 토큰당 실제 비용이다. 가트너 조사에서도 생성형 AI의 예측하기 어려운 비용 급증을 관리하는 것이 CIO의 최우선 과제 중 하나로 꼽혔다. 최적화의 목표는 이론적 성능이 아니라 경제성이다.
• 또한 AI 추론은 태생적으로 하이브리드 배포 환경을 전제로 한다. 추론을 중앙 집중식의 단일하고 균질한 환경에서만 처리하기는 사실상 불가능하다. 금융, 의료처럼 규제가 강한 산업이나, 내부 고유 데이터를 기반으로 운영되는 업무에서는 데이터가 보안 경계를 벗어나선 안 된다. 따라서 추론은 온프레미스, 엣지, 또는 보안이 보장된 콜로케이션 등 다양한 환경에서 수행돼야 한다. 중요한 워크로드를 일반적인 클라우드 API 엔드포인트로 밀어넣는 방식은 이러한 규제 및 보안 요건을 충족하기 어려워, 기업은 자연스럽게 하이브리드 및 엣지 아키텍처로 이동하고 있다. 여기에 더해 하드웨어 역시 CPU, GPU, DPU 등 다양한 프로세서가 혼재된 이기종 환경이기 때문에 플랫폼은 이를 모두 매끄럽게 관리할 수 있어야 한다.

CIO의 필수 과제는 ‘AI 추론 플랫폼의 완성’

통합 플랫폼의 목적은 하나의 모델로 강제 통일하는 것이 아니다. 기업이 요구하는 보안과 비용 관리 기준을 충족하면서 훨씬 다양한 모델, 에이전트, 애플리케이션을 활용할 수 있도록 하는 거버넌스 계층을 마련하는 데 있다.

‘단순 확장’에서 ‘스마트 확장’으로의 전환은 기술 리더에게 주어진 핵심 과제다. AI의 미래 가치는 훈련한 모델이 아니라, 추론 운영을 통해 얼마나 안정적인 마진을 확보하는가에 달려있다.

모든 기술 리더는 AI 손익 센터의 플랫폼 소유자이자 재무 설계자로서 역할을 수행해야 한다. 이 구조적 변화가 이루어져야만 데이터 사이언스팀이 보안·규제 준수·비용이 최적화된 기반 위에서 기존 속도를 유지하며 혁신을 이어갈 수 있다.

플랫폼을 정착시키고 스마트 확장 전략을 도입하면, AI 비용이 걷잡을 수 없이 증가하는 상황에서 벗어나 지속 가능한 수익 기반 경쟁력을 확보할 수 있다. 남은 선택지는 분명하다. 분산된 AI 환경의 비용과 혼란을 계속해서 수동적으로 관리할 것인지, 아니면 추론을 수익 창출 기반으로 전환하는 AI 손익 센터를 구축해 장기적 경쟁우위를 확보할 것인가다.
dl-ciokorea@foundryco.com