← Return to the book

FUTURECENTRAL PRESS · BOOK SAMPLE

AI for Sustainability

From ESG Analytics to Agentic Operations

Chapter 14: Building AI-for-Sustainability Capability: A CSO Perspective

Vendor Selection, Build-Versus-Buy, Talent, and Governance From the Chief Sustainability Officer’s Seat

Learning Outcomes

By the end of this chapter, the reader will be able to:

1. Explain why a chief sustainability officer building AI capability makes different decisions than a chief technology officer leading an AI transformation.

2. Apply the build-versus-buy logic across the three waves, recognizing what is procurable, what must be configured, and what must be built internally.

3. Describe the talent profiles, budget structures, and governance the reorganized function requires across the three waves.

4. Evaluate how change management, not technology, determines whether AI capability delivers value in the sustainability function.

5. Assess how Indian companies of different sizes, from the top thousand to the MSME, can realistically build or access AI-for-sustainability capability.

What This Chapter Is and Is Not

This chapter turns the reorganization of the previous chapter into a practical program. If the sustainability function must restructure around continuous data flows, the chief sustainability officer must make a series of capability-building decisions, on what to buy, what to build, whom to hire, what to budget, and how to govern, and those decisions differ from the ones a chief technology officer makes. The chapter walks through capability building from the officer’s seat, applying the procurement-and-governance literacy of Chapter 2 to the reorganized function of Chapter 13.

It is a capability-building guide for the sustainability function specifically, not a general AI-transformation playbook, which the enterprise-AI titles in the portfolio provide. Its subject is the decisions the officer faces, framed by the three waves, not the technical detail of the systems. The chapter connects backward to Chapter 13, whose reorganized function it now equips, and to Chapter 2, whose procurement discipline it applies, and forward to Chapter 15, where the Indian vendor ecosystem the officer buys from is mapped. It is the operational chapter of the book’s final part: where Chapter 13 argued what the function becomes, this argues how to build it, for companies of very different sizes and budgets.

Opening Vignette

A capability-building decision, 2026. The chief sustainability officer of a large Indian company had been told by the board to build the function’s AI capability, and the officer’s first instinct was to ask the chief technology officer how. The conversation revealed how different the two roles’ decisions were. The chief technology officer thought in terms of platforms, engineering teams, and build-versus-buy at enterprise scale; the officer’s problem was narrower and stranger, to acquire specific sustainability capabilities, configure them to the company’s disclosure obligations, govern their autonomous decisions, and do it with a small team and a modest budget.

The decisions did not map onto the technology officer’s framework. The officer was not building AI; the officer was buying it, mostly, from a market of sustainability-specific vendors, and the skill that mattered was not engineering but procurement and governance, the discipline of Chapter 2. Some capability was a straightforward purchase: an ESG data platform, a carbon-accounting tool. Some required heavy configuration to the company’s frameworks and data. And the newest, agentic capability, was partly a purchase and partly an internal build, and it came with a governance burden the technology officer’s playbook did not address.

The budget conversation was equally distinctive. The officer was not asking for an enterprise AI transformation budget; the officer needed to fund vendor subscriptions, a few specialized hires, configuration work, and governance, in a function that had historically been resourced as overhead. And the officer faced a question the technology officer never did: how a company a tenth the size, or a supplier that was a micro-enterprise, could build any of this capability at all, because the company’s own sustainability depended on a supply chain of firms with no budget for it.

The officer needed a capability-building logic of their own, fitted to the sustainability function, the three waves, and the Indian reality of a few large companies and a vast tail of small ones. That logic is the subject of this chapter.

This chapter builds the chief sustainability officer’s capability-building logic: why it differs from the chief technology officer’s, how the build-versus-buy decision changes across the three waves, what talent, budget, and governance the function needs, and how Indian companies of very different sizes can realistically participate.

1. Why the CSO’s Decisions Differ From the CTO’s

A chief sustainability officer building AI capability faces a procurement, configuration, and governance problem, not the engineering problem a chief technology officer solves, and confusing the two leads to the wrong decisions. The reorganized function needs AI, but the officer building it is buying and governing capability, not engineering it, and the decisions follow from that distinction. The officer who borrows the technology officer’s framework wholesale will mis-budget, mis-hire, and mis-govern.

The first difference is that the officer procures capability rather than building it. As the book has argued throughout, the three waves reach sustainability largely as products: ESG data platforms, generative reporting tools, emerging agentic systems. The officer’s core skill is therefore the procurement-and-governance literacy of Chapter 2, the ability to evaluate, select, and govern bought capability, not the engineering skill to build it. The function does not need a large engineering team; it needs skilled buyers and governors.

The second difference is that sustainability capability is domain-specific and must be configured to the company’s obligations. A general AI platform does not produce a BRSR Core disclosure or screen suppliers against a taxonomy without configuration to the specific frameworks, data, and obligations the company faces. The officer’s capability-building includes substantial configuration work, fitting bought tools to the company’s domain, which is a different activity from the technology officer’s platform engineering and requires sustainability domain knowledge alongside the tool.

The third difference is that the officer carries a governance burden the technology officer’s playbook does not fully address. The autonomous systems the officer deploys make sustainability decisions for which the officer is accountable, the responsibility Chapter 12 made central, and governing them, bounding, logging, owning, overriding, is part of the capability the officer must build. The technology officer’s governance is about system reliability and security; the officer’s adds accountability for sustainability decisions and the disclosure obligations they touch. The governance is heavier and more specific.

The fourth difference is scale: the officer builds capability for a small function and must extend it to a supply chain that cannot build its own. The officer’s function is small, so the capability must be efficient and mostly bought. And the company’s sustainability, especially its Scope 3 and value-chain obligations, depends on suppliers, many of them micro-enterprises, that cannot build any AI capability at all. The officer’s capability problem therefore extends beyond the company to how the supply chain can participate, which is a problem the technology officer, building for the enterprise, does not face. The rest of the chapter builds the officer’s logic across these differences.

The central decision the officer faces, repeated for each capability, is whether to build or buy, and the answer changes systematically across the three waves. The framework that follows lays out that logic.

Framework: The Build-Versus-Buy Decision Across the Three Waves

The Build-Versus-Buy Decision framework is the chapter’s principal framework: a wave-by-wave guide to what the sustainability function should buy, what it must configure, and what it must build and govern internally. The framework gives the officer a default answer for each wave, recognizing that the build-versus-buy balance shifts systematically as the capability moves from mature and standardized to new and context-specific. The officer applies it to each capability and adjusts for the company’s circumstances.

For Wave 1, the default is buy, because predictive measurement is mature and standardized. ESG data platforms, carbon-accounting tools, and the document-extraction and anomaly-detection capabilities of the measurement chapters are commodity products from a competitive vendor market. The officer should buy these, not build them, and spend the saved effort on selecting well and integrating cleanly. Building Wave 1 capability internally is almost always a mistake, because the market does it better and cheaper.

For Wave 2, the default is buy and configure, because generative reporting is procurable but useless without domain-specific configuration. Generative tools for disclosure drafting and framework translation are available, but they deliver value only when configured to the company’s specific frameworks, data, and obligations, and grounded in retrieval over the company’s real figures. The officer buys the capability and invests in configuration, which is where the value is won or lost. The buy is easy; the configuration is the work.

For Wave 3, the default is buy, build, and govern, because agentic capability is partly procurable, partly context-specific, and heavily governance-dependent. Emerging agentic vendors offer workflows, but configuring agents to the company’s context, deciding what they may do autonomously, and governing their decisions is partly an internal build and entirely a governance responsibility. The officer buys what the market offers, builds the configuration and bounds the autonomy internally, and governs the result, carrying the accountability of Chapter 12. Wave 3 is where the officer’s internal capability and governance matter most.

The framework is used to set the default and to locate the real work at each wave. Buy Wave 1 and select well; buy and configure Wave 2; buy, build, and govern Wave 3. The pattern is that the build-and-govern share rises as the capability gets newer, which tells the officer where to concentrate internal effort and budget: on configuring and governing the newer ones rather than on building mature tools. The framework’s value is that it prevents both errors, building what should be bought and buying what must be governed, and it scales down for smaller companies by shifting more toward buy and shared services.

The framework’s first default is to buy Wave 1 capability. The next section examines how the officer selects and integrates it.

2. Wave 1 Capability: Selecting and Integrating Procured Tools

Wave 1 measurement capability is a purchase, and the officer’s work is selecting the right vendor and integrating the tool cleanly, not building anything. The predictive AI that measures emissions, extracts ESG data, and detects anomalies is a mature, competitive product market, and the officer who tries to build it internally wastes resources the market has already spent. The capability decisions are procurement decisions.

Vendor selection is the first decision, and it is governed by the question set of Chapter 2. The officer evaluates ESG data platforms and carbon-accounting tools against the procurement-and-governance questions: what data they depend on, how they behave when wrong, how they fit the workflow, and who is accountable. The Indian and global vendor market offers many options, and the officer’s task is to select the one whose capability, data fit, and governance suit the company, testing each against the company’s own data rather than the vendor’s demonstration. The selection is the high-leverage decision, because a poorly chosen tool wastes the configuration and integration that follow.

Integration is the second decision, and it determines whether the bought capability delivers value. A measurement tool delivers value only when integrated into the company’s data sources and workflows, so that its outputs reach the people and processes that use them. The workflow-integration layer that Chapter 2 identified as the most neglected is where Wave 1 capability succeeds or fails: an accurate tool whose outputs no one acts on creates no value. The officer invests in clean integration, which is unglamorous and decisive.

The build temptation should be resisted, with rare exceptions. Some companies, especially large ones with strong engineering, are tempted to build Wave 1 capability internally for control or customization. This is almost always a mistake, because the vendor market is mature and the company’s comparative advantage is not in building measurement tools. The rare exception is a genuinely unique measurement need the market does not serve, and even then the officer should buy where possible and build only the irreducible gap. The default is buy, and the burden of proof is on building.

For Wave 1, the officer’s budget is mostly subscription and integration, not development. The cost structure is vendor fees plus the internal effort to integrate and govern, not a development budget. This is affordable for a large company and, importantly, scalable down: smaller companies can buy the same tools at smaller scale, and the subscription model means capability is rentable rather than requiring capital. Wave 1 capability is the most democratically accessible of the three, which matters for the Indian tail of smaller companies. The harder waves are less forgiving.

Wave 1 is bought and integrated. Wave 2 is bought too, but it fails without the configuration that is the officer’s real work, which the next section examines.

3. Wave 2 Capability: Buying the Tool, Doing the Configuration

Wave 2 generative capability is procurable, but its value comes entirely from configuration to the company’s frameworks and data, which is the officer’s real work and the place the capability most often fails. A generative reporting tool is easy to buy and easy to demonstrate, and easy to deploy badly. The difference between a tool that produces credible disclosures and one that produces fluent but ungrounded text is the configuration, and the officer who buys without configuring has bought a liability.

The configuration fits the generative capability to the company’s specific obligations. A generative tool must be configured to draft the company’s actual BRSR principles, translate to the specific frameworks the company faces, and ground its output in the company’s real, retrieved data rather than its general training. This configuration is domain work, requiring someone who knows both the tool and the company’s sustainability obligations, and it is where the procurement-and-governance literacy meets sustainability expertise. The configuration, not the purchase, is the capability.

Grounding the generative tool in the company’s data is the configuration that matters most. As Chapter 2 argued, a generative tool without retrieval over the company’s real figures will produce fluent fabrication, which in a disclosure context is a serious risk. The officer’s configuration must ensure the tool drafts from the company’s actual data with citations a reviewer can check, which is a technical configuration with governance consequences. The officer who skips this has bought the Wave 2 paradox: a tool that makes the company’s greenwashing more fluent.

The talent for Wave 2 is the hybrid profile: sustainability knowledge plus tool fluency. Configuring a generative tool to a company’s obligations needs a person who understands the disclosure frameworks and the tool’s behavior, the AI-fluent sustainability professional the previous chapter identified as scarce and valuable. The officer who has this profile in the team configures well; the officer who has only domain experts or only technologists configures poorly. Building or hiring this hybrid profile is a central capability decision.

For Wave 2, the budget is buy plus a significant configuration and review investment. The vendor fee is a fraction of the cost; the larger cost is the configuration and the ongoing human review that grounded generative output requires. The officer who budgets only for the subscription under-resources the capability and gets the fluent-but-ungrounded failure. The budget must fund the configuration and the review, which is the part smaller companies struggle with, because the configuration effort does not scale down as cleanly as the subscription does. This is the first point where the Indian size gradient bites.

Wave 2 is bought and configured. Wave 3 adds an internal build and a governance burden that make it the hardest capability to acquire responsibly, which the next section examines.

4. Wave 3 Capability: Buying, Building, and Governing the Agentic Layer

Wave 3 agentic capability is partly bought, partly built internally, and entirely a governance responsibility, which makes it the hardest of the three to acquire well and the one where the officer’s internal capability matters most. Agentic systems are the newest and least standardized, so more of the capability is context-specific and internal, and all of it must be governed. The officer who buys an agentic tool and deploys it without building the configuration and the governance has taken on a liability the previous waves did not carry.

The buy is what the emerging agentic vendor market offers, which in 2026 is real but early. Vendors offer agentic ESG workflows, supplier-engagement agents, and monitoring systems, and the officer buys what fits, applying the sharper procurement questions Chapter 2 specified for agentic capability: what the system does autonomously, what it escalates, how its actions are logged, and who is accountable. The market is immature, so the officer buys cautiously, treats most claims as early-stage, and structures contracts so that an immature capability does not become a liability.

The build is the configuration of agents to the company’s context and the bounding of their autonomy, which cannot be fully bought. Deciding what an agent may do on its own, in the company’s specific context, with the company’s risk tolerance, is an internal decision and a configuration task, not a purchase. The officer builds the bounds, the escalation rules, and the integration with the company’s systems, which is where the internal capability of the reorganized function, the agentic-system steward of Chapter 13, does its work. This build is modest in engineering but heavy in judgment.

The governance is the largest part, because the officer is accountable for what the autonomous systems decide. Every agentic deployment carries the accountability obligation of Chapter 12: the system’s decisions must be bounded, logged, explainable, and overridable, with a named human owner. Building this governance, the oversight, the audit trail, the override, is part of acquiring the capability, not an add-on, and the officer who deploys agentic capability without it is exposed. The governance is where the officer’s responsibility concentrates and where the capability-building is hardest.

For Wave 3, the budget funds buying, configuring, building governance, and the specialized talent to do all three, and it is the least accessible to smaller companies. The cost is the vendor fee plus the internal configuration, the governance build, and the scarce talent to steward the systems, which is a meaningful investment available mainly to larger companies. This is where the Indian size gradient is steepest: agentic capability is realistic for the top tier and largely out of reach for smaller companies and the MSME tail, which must access it, if at all, through shared platforms and vendor-provided governance rather than building their own. A large company should also consider how its agentic capability can extend to its suppliers, because its own Scope 3 depends on it.

The capability decisions across the three waves resolve into questions of talent, budget, change management, and how companies of different sizes participate. The next section addresses them.

5. Talent, Budget, Change Management, and the Size Gradient

Capability is delivered by talent, funded by an appropriately structured budget, realized through change management, and constrained by company size, and the officer must manage all four. The technology is procurable; whether it delivers value depends on the people who run it, the budget that resources it, the change that embeds it, and the company’s capacity to afford it. These are the officer’s deepest capability-building responsibilities.

The talent profile the function needs is the AI-fluent sustainability professional, which is scarce and must be built as much as hired. The reorganized function needs people who combine sustainability domain knowledge with the procurement, configuration, and governance literacy the three waves require, and this hybrid profile is scarce in a market where sustainability experts and AI experts have trained separately. India’s deep and growing AI talent base helps, with the country among the world leaders in AI skill penetration and its AI workforce projected to expand substantially by the late 2020s, but the specific sustainability-and-AI hybrid must largely be developed inside the function through training, not just recruited.¹ The officer invests in building the profile, because the market cannot supply enough of it.

The budget structure shifts from development to subscription, configuration, governance, and talent, which is unfamiliar to a function resourced as overhead. The reorganized function’s budget is an ongoing structure, not a one-time development cost, of vendor subscriptions, configuration effort, governance, and specialized salaries, weighted toward configuration and governance as the capability gets newer. The officer must reframe the function’s budget from compliance overhead to capability investment, and justify it by the value the reorganized function delivers, the strategic insight, the avoided risk, the credible disclosure, not only by compliance. This reframing is itself a capability-building task.

Change management, not technology, determines whether the capability delivers value, which is the lesson the broader AI literature teaches. A capable tool whose outputs no one trusts or acts on creates no value, and the history of enterprise AI is full of capable systems that failed on adoption rather than technology. The officer must invest in embedding the capability into the function’s and the company’s workflows and incentives, which is the unglamorous, decisive work that the enterprise-AI literature identifies as where most AI value is won or lost. The officer who funds the tool but not the change has funded a demonstration.

The Indian size gradient means capability-building looks very different for the top thousand companies and for the MSME tail, and the officer of a large company must consider both. A top-1000 listed company can build the full capability across the three waves; a mid-size company buys more and builds less; a micro-enterprise cannot build any of it and can participate only through shared platforms, vendor-provided capability, and the subsidized national compute and tools that lower the barrier.² A large company’s sustainability officer faces this as a practical concern, not a charitable one, because the company’s Scope 3 and value-chain obligations depend on suppliers who cannot build capability, so the officer’s capability-building includes enabling the supply chain to participate, through shared tools and requirements that the suppliers can actually meet. The size gradient is not someone else’s problem; it is in the large company’s own value chain.

Capability-building decisions are shaped by the regulatory mandates that determine what the function must be able to do. The comparison box sets out how those mandates drive the investment across jurisdictions.

Regulatory Comparison Box: How Mandates Shape Capability Investment Across Four Jurisdictions

This box compares how the disclosure and assurance mandates of the four jurisdictions determine the AI capability a sustainability function must build. (As of June 2026.)

DimensionIndiaEuropean UnionUnited StatesASEAN
Mandate driving capabilityBRSR and BRSR Core, with assurance to the top 1,000³CSRD and ESRS, broad and assuredFragmented; California binding at the edgeNational regimes; advancing
Capability the mandate forcesContinuous, assurance-ready data; multi-framework reportingBroad, assured, double-materiality reportingVariableEmerging
Vendor market availableMaturing Indian and global vendors⁴Deep global and European vendor marketDeep vendor marketDeveloping
Compute and cost supportIndiaAI Mission subsidized compute lowers the barrier⁵Market-fundedMarket-fundedVariable
Effect on smaller firmsSteep size gradient; MSMEs need shared platformsSignificant burden; proportionality debatedLighter where rules do not bindEmerging

The box shows that the mandate sets the capability floor: where assurance is required, as under India’s BRSR Core and the European Union’s CSRD, the function must build continuous, assurance-ready capability, which is a higher bar than a voluntary-disclosure regime sets. India’s distinctive features are a maturing rather than deep vendor market, which the next chapter examines, and the subsidized national compute that lowers the barrier for smaller players and startups. The size gradient is steepest where the mandate is strict and the budgets are thin, which describes much of the Indian top-1000-and-tail structure, and it is why shared platforms and vendor-provided capability matter more in India than in markets of uniformly large firms.

6. India Cases

India’s capability-building story spans the top-1000 company that can build the full stack and the MSME that can build none of it, and the gap between them is the defining feature of the Indian context. Two cases illustrate the range.

The top-1000 listed company building the full capability. A large Indian listed company subject to BRSR Core assurance builds capability across the three waves: it buys and integrates Wave 1 measurement, buys and configures Wave 2 reporting, and buys, builds, and governs an emerging Wave 3 agentic layer, staffed by a reorganized function with the hybrid talent the chapter describes.⁶ The case shows capability-building as the chapter recommends it, with the build-and-govern effort concentrated on the newer waves and the budget reframed from overhead to investment. Such a company can also extend capability to its suppliers, using its scale to provide or require tools the suppliers could not build alone, which is how the large company addresses the Scope 3 dependency the chapter identified.

The MSME that cannot build capability and must access it through shared means. A micro, small, or medium enterprise in an Indian supply chain cannot build any of the capability the large company builds, lacking the budget, the talent, and the scale, yet it faces growing pressure to provide emissions and ESG data to the customers whose Scope 3 depends on it.⁷ The case shows the other end of the gradient, where capability must be accessed rather than built, through shared platforms, vendor-provided tools, the subsidized national compute that lowers the cost of AI, and the requirements and support that large customers provide. The chapter’s point is that the MSME’s participation is a shared responsibility, of the vendors who must build affordable tools, the large customers who depend on the data, and the policy that subsidizes the compute, because the Indian sustainability transition cannot leave its vast small-enterprise base unable to participate.

India’s capability-building happens within a global vendor market and a global body of practice on AI capability. One global case captures the build-versus-buy lesson.

7. Global Case

The enterprise build-versus-buy lesson: capability is mostly bought, and value comes from configuration, integration, and change, not from building. The broad experience of enterprises building AI capability, across functions and geographies, teaches a consistent lesson that applies directly to the sustainability function: the organizations that succeed mostly buy their AI capability and invest in configuring, integrating, and embedding it, while those that try to build what the market already offers waste resources and stall.⁸ The case is instructive because it generalizes the chapter’s framework. The build-versus-buy balance favors buying the mature and standardized and reserving internal effort for the context-specific and the governance-heavy, which is exactly the wave-by-wave pattern the chapter recommends. The deeper lesson, from the enterprise-AI literature the book has referenced, is that most AI value is won or lost not in the technology but in the workflow integration and change management, which is why the chapter insists the officer fund the configuration and the change, not only the tool. The sustainability function is not exempt from this lesson; it is a recent and instructive instance of it.

Practitioner’s Lens: The CSO as Capability Builder

The chief sustainability officer building capability acts as a buyer, configurer, and governor of AI, and the job is to put the function’s limited resources where they create value: in selection, configuration, governance, and change, not in building what the market sells. The officer who has internalized the chapter’s logic does not try to engineer AI; the officer buys it well, configures it to the company, governs its decisions, and embeds it in the function. The working decisions follow the build-versus-buy pattern across the waves.

The officer’s first discipline is to buy the mature and reserve internal effort for the new and the governance-heavy. The officer buys Wave 1 measurement outright, buys and configures Wave 2 reporting, and concentrates internal build and governance on the Wave 3 agentic layer, matching effort to where it is needed. Building what should be bought wastes resources; buying what must be governed takes on liability. The discipline is to apply the framework’s default and adjust only with reason.

The officer’s second discipline is to fund and build the hybrid talent and the change management that make capability deliver. The officer invests in developing the AI-fluent sustainability professionals the function needs, since the market cannot supply enough, and funds the configuration, integration, and change that turn a bought tool into a used capability. Change management is the decisive investment here, not an afterthought, because the history of enterprise AI shows that adoption, not technology, determines value.

The officer’s third discipline is to think beyond the company to the supply chain, because the company’s sustainability depends on suppliers who cannot build capability. The officer designs requirements suppliers can meet, provides or subsidizes tools where the company’s Scope 3 depends on the data, and supports the shared platforms and policy that let the MSME tail participate. Capability-building, on this view, is a value-chain program, not only an internal one, and the company’s own targets depend on enabling the small firms it buys from. The officer who builds only inside the company’s walls leaves the largest part of its footprint unmeasured.

This Lens is illustrative; it composites the working reality of chief sustainability officers building AI capability in Indian companies rather than depicting a single named individual.⁹

Applied Exercise: A Capability-Building Plan and Budget

Three to five hours. Individual or small-group submission. Deliverable: a five-to-six-page capability-building plan, with an indicative budget, addressed to a chief executive.

Step 1: Scope the company and its obligations. Choose a company and state its disclosure and assurance obligations, which determine the capability floor it must reach. Note its size, because size shapes the build-versus-buy balance.

Step 2: Apply the build-versus-buy framework. For Wave 1, Wave 2, and Wave 3, specify what the company should buy, what it must configure, and what it must build and govern internally, with reasons. Identify where the company should resist the temptation to build.

Step 3: Specify the talent. Identify the talent profiles the plan requires, especially the AI-fluent sustainability professionals, and state which should be hired and which developed internally. Be realistic about the scarcity of the hybrid profile.

Step 4: Structure the budget. Build an indicative budget across subscriptions, configuration, governance, talent, and change management, weighted as the framework suggests. State the share going to change management explicitly.

Step 5: Address the supply chain. Specify how the company will enable the suppliers its Scope 3 depends on to provide data, given that many cannot build capability. Recommend the shared tools, requirements, or support the company should provide.

Step 6: Submit. A five-to-six-page plan with an indicative budget and at least four referenced sources, including the company’s disclosures and credible analysis of the vendor market and talent supply. Distinguish your recommendations from sourced facts, and label vendor claims as such.

Summary and Bridge

Building AI-for-sustainability capability is a procurement, configuration, and governance task, and the build-versus-buy balance shifts systematically across the three waves. A chief sustainability officer builds capability differently than a chief technology officer, because the officer buys rather than engineers, configures to the company’s obligations, carries a heavier governance burden, and must extend capability to a supply chain that cannot build its own. The framework’s defaults are to buy Wave 1 and select well, buy and configure Wave 2, and buy, build, and govern Wave 3, with the internal build-and-govern share rising as the capability gets newer.

Capability is delivered by talent, funded by a reframed budget, and realized through change management, with company size the binding constraint. The function needs the scarce AI-fluent sustainability professional, which must be developed as much as hired, drawing on India’s deep AI talent base. The budget shifts from development to subscription, configuration, governance, and talent, and must be reframed from compliance overhead to capability investment. Change management, not technology, determines whether capability delivers value, which is the consistent lesson of enterprise AI. And the Indian size gradient means the top thousand can build the full stack while the MSME tail must access capability through shared platforms, subsidized compute, and the support of the large customers whose value chains depend on them.

For India, the capability problem is a shared one, because the large company’s sustainability depends on the small enterprise’s participation. The officer of a large company must build capability across its value chain, not only inside the company’s walls, designing requirements suppliers can meet and providing the tools and support that let them participate, because the company’s own footprint and targets depend on the data the suppliers provide. Capability-building is therefore an ecosystem problem as much as a corporate one, which is the bridge to the next chapter.

The next chapter maps the ecosystem the officer buys from and the suppliers depend on: India’s climate-tech and sustainability-technology landscape. From the carbon-MRV and ESG-data firms the book has named to the emerging agentic-sustainability startups, India is building the vendor base that this chapter’s capability-building assumes. Chapter 15 assembles that ecosystem into a single view, identifies its strengths and gaps, and positions Indian climate-tech in the global landscape.

Endnotes

1. India ranks among the world leaders in AI skill penetration, per the Stanford AI Index, and its AI talent pool is projected to expand substantially by the late 2020s, per NASSCOM-Deloitte estimates (see Chapter 2). The specific sustainability-and-AI hybrid profile, however, must largely be developed within functions rather than recruited ready-made.

2. The IndiaAI Mission provides subsidized national compute capacity, lowering the cost of AI for startups, researchers, and smaller organizations (see Chapter 2). Smaller Indian companies and MSMEs access AI-for-sustainability capability principally through shared platforms and vendor-provided tools rather than internal builds.

3. Securities and Exchange Board of India, BRSR and BRSR Core, with reasonable assurance phased across the top 1,000 listed entities (see Chapter 3).

4. The Indian sustainability-technology vendor market is maturing rather than deep, and is mapped in Chapter 15.

5. See endnote 2.

6. The case describes a large Indian listed company subject to BRSR Core assurance; it is presented illustratively to show full-stack capability-building rather than to report a specific company’s internal program. See composite-case flag at endnote 9.

7. The case describes a micro, small, or medium enterprise in an Indian supply chain; it is presented illustratively to show the access-rather-than-build dynamic at the small-enterprise end of the gradient. See composite-case flag at endnote 9.

8. The reference is to the broad enterprise experience of building AI capability, as documented in the management and enterprise-AI literature, including the work referenced in the portfolio’s enterprise-AI titles; the characterization is a synthesis of that literature rather than a report of a specific organization.

9. The Practitioner’s Lens narrative and the India cases in this chapter are illustrative composites drawn from the working reality of chief sustainability officers building AI capability in Indian companies of different sizes; no single individual or institution is depicted.

Key Terms

Capability building. The chief sustainability officer’s program of acquiring, configuring, governing, and embedding the AI the reorganized function needs, distinct from a chief technology officer’s engineering-led AI transformation.

Build versus buy. The decision, for each capability, between building it internally and buying it from a vendor. The chapter’s default shifts across the waves: buy Wave 1, buy and configure Wave 2, buy and build and govern Wave 3.

Procurement-and-governance literacy. The competence, from Chapter 2, to evaluate, select, and govern bought AI capability rather than build it. The core skill of the capability-building chief sustainability officer.

Configuration. The work of fitting a bought tool to the company’s specific frameworks, data, and obligations. For Wave 2 especially, the configuration, not the purchase, is where the capability is won or lost.

Grounding. Configuring a generative tool to draft from the company’s real, retrieved data with checkable citations, rather than from its general training. The configuration that prevents fluent fabrication.

Agentic-system steward. The internal role, introduced in Chapter 13, that configures and governs the function’s autonomous systems. Central to acquiring Wave 3 capability responsibly.

Hybrid talent profile. The AI-fluent sustainability professional who combines domain knowledge with procurement, configuration, and governance literacy. Scarce, and developed within the function as much as hired.

Change management. The work of embedding a capability into the function’s and company’s workflows and incentives so that its outputs are trusted and acted on. Identified by the enterprise-AI literature as where most AI value is won or lost.

Size gradient. The wide difference in capability-building between the top-1000 Indian company that can build the full stack and the MSME that can build none of it and must access capability through shared means.

Shared platforms. Vendor-provided or pooled capability that lets smaller companies and MSMEs access AI-for-sustainability without building it, important for participation across the Indian size gradient.

Value-chain capability. The extension of a large company’s AI-for-sustainability capability to its suppliers, through requirements, tools, and support, because the company’s Scope 3 and targets depend on suppliers who cannot build capability alone.

Capability investment versus compliance overhead. The reframing of the sustainability function’s budget from a cost of compliance to an investment in capability, justified by the strategic value the reorganized function delivers.

Discussion Questions

1. The chapter argues a chief sustainability officer’s capability decisions differ fundamentally from a chief technology officer’s. Identify the difference you find most consequential, and how getting it wrong would harm a capability-building program.

2. Apply the build-versus-buy framework to a specific capability, such as Scope 3 supplier engagement. What should be bought, configured, and built internally, and how would your answer change for a smaller company?

3. The chapter argues that for Wave 2, the configuration, not the purchase, is the capability. Describe what configuring a generative reporting tool to a company’s obligations actually involves, and what happens if it is skipped.

4. Change management, not technology, is said to determine whether capability delivers value. Design the change-management plan you would fund alongside a new AI tool in a sustainability function, and estimate its share of the budget.

5. The Indian size gradient leaves the MSME unable to build capability. Whose responsibility is it to enable MSME participation, the vendors, the large customers, or the government, and what is the most effective intervention?

6. The chapter says a large company’s capability-building must extend to its supply chain because its Scope 3 depends on it. Design a realistic way a large company could enable its smaller suppliers to provide emissions data.

7. The chapter recommends reframing the function’s budget from compliance overhead to capability investment. Construct the business case a chief sustainability officer would make to a chief financial officer to justify the reframing.

Further Reading

The foundational preparation for this chapter is Chapter 2 on procurement-and-governance literacy and Chapter 13 on the reorganized function, which together define the buyer the officer must be and the function the capability must serve. The chapter applies their arguments to the practical decisions of capability-building, and a reader should hold both in mind.

On the build-versus-buy decision and AI capability-building in the enterprise generally, the management literature on AI adoption and the portfolio’s enterprise-AI titles develop the framework at length for other functions, and the consistent finding that change management and workflow integration, not technology, determine AI value is the most important lesson to carry into the sustainability function. The literature on AI talent and the future of work supplies the context for the hybrid-profile argument.

On the Indian vendor market the officer buys from, the next chapter is the direct continuation, and the public material of the Indian and global sustainability-technology vendors, read against the procurement discipline of Chapter 2, is the practical reference for selection. On the MSME participation problem, the work on decarbonizing Indian supply chains and the role of shared platforms and policy support supplies the context for the chapter’s value-chain argument. The companion site maintains current material on the vendor market, the talent supply, and the capability-building tools that this chapter treats as a moving target.