AI's Expensive Acceleration: Gemini 4 Carbon and The AI-Savvy Leader

On October 28, Alphabet used its third-quarter earnings call to announce Gemini 4 Carbon, a new frontier model it described as its strongest yet, with cybersecurity and long-horizon capabilities. The company said it would first make the model available to a subset of trusted cyber defenders before broadening access, as described in Google’s announcement and The Verge’s same-day report. That announcement arrived alongside a story about a different kind of capability: the enormous investment required to build, train, and serve increasingly powerful systems.

For leaders, the news is not simply “AI is moving fast.” The more useful question is whether an organization can connect each new capability to a real business objective, assign responsibility for its use, and measure whether the investment is paying off. That is the central management problem explored in The AI-Savvy Leader: Nine Ways to Take Back Control and Make AI Work by David De Cremer, a book whose message has become especially relevant as AI development turns into a high-stakes operating decision.

The October 28 earnings coverage reported that Alphabet’s revenue grew 25% year over year in the quarter, while capital expenditures reached $51.36 billion. Those figures are not a forecast for every company, and a single quarter cannot tell us whether every AI investment will succeed. They do, however, make one point concrete: the frontier race is also an infrastructure and capital-allocation story. A new model is both a technical milestone and a decision about who pays, what gets prioritized, and how the return will be judged.

For readers who want the book itself, The AI-Savvy Leader offers a leadership lens rather than a technical manual. De Cremer’s publisher description says the book asks executives to take a more active role in AI transformation, connecting AI use to organizational strategy instead of leaving key decisions exclusively to technology teams. That distinction is useful well beyond large technology companies. It applies to a small firm deciding whether to automate customer support, a school weighing an AI tutor, or a professional choosing when to trust an assistant with research.

The latest AI story is about more than a model

Alphabet’s call provides a clear example of how model news and operating strategy now arrive together. The company announced Gemini 4 Carbon during the call and said Gemini 4 Argon had launched two weeks earlier. In the same presentation, executives discussed demand for AI infrastructure, cloud customers, product usage, and the need to bring more capacity online. These are the company’s own statements, recorded in its Q3 2026 earnings-call transcript; they should be read as management’s account of its products and business, not as an independent evaluation of model performance.

That distinction matters. Company announcements tell us what a company says it has built, what it plans to do, and what it is prioritizing. They do not by themselves prove that a feature will work reliably in every setting or create value for every customer. A prudent organization treats a launch announcement as a reason to investigate and test, not as evidence that it should immediately redesign a workflow around the product.

The gap between “available” and “valuable” is where leadership becomes essential. A model can be impressive in a demonstration and still be a poor fit for a particular task because of privacy requirements, integration costs, latency, error tolerance, or the need for human review. Conversely, a narrower model or simpler automation may deliver more useful results if it solves a frequent problem with clear boundaries. The product choice should follow the problem definition, not replace it.

Why does AI adoption make leadership more important?

It is tempting to interpret wider adoption as proof that organizations have already figured out how to use AI well. The evidence is more mixed. Stanford HAI’s 2026 AI Index economy chapter reports that 88% of surveyed organizations used AI in 2025. That is an adoption measure, not a measure of return on investment, accuracy, employee confidence, or the quality of governance. It tells us AI has entered organizational life; it does not tell us that each use is worthwhile.

The same chapter reports that private AI investment grew 127.5% in 2025 and describes the growth of corporate AI investment as a broader economic trend. A large investment total can signal strong expectations and intense competition, but it is not an outcome by itself. Leaders still need to ask what work is being improved, what the baseline was, what the full cost includes, and what evidence would cause the organization to stop or change course.

De Cremer’s book is a practical counterweight to the idea that AI transformation is merely a technology purchase. The publisher’s description frames the leadership task around familiar executive skills: forming a vision, communicating clearly, and executing strategy. In an AI context, those habits require executives to understand what the tool is intended to do, what it should not do, and how the organization will recognize failure early. The book’s point is not that every leader must become an engineer. It is that leaders cannot outsource the purpose, trade-offs, and accountability of a change that affects the organization.

This is especially important when product teams and senior leadership use different definitions of success. A technical team might focus on benchmark performance or uptime. A sales team may care about response time. A customer may care whether the answer is correct and understandable. A compliance lead may focus on data access and auditability. A leadership team must bring those viewpoints together before scaling a system, or local wins can create organization-wide problems.

From model launch to a disciplined pilot

A useful way to apply the book’s leadership frame is to translate curiosity about a new AI release into a small, measurable pilot. The following sequence keeps the business question in front of the product:

1. Name the job to be done. Describe the task in plain language, including who performs it, how often it occurs, and what a good result looks like. “Use AI in customer service” is too broad. “Draft a first response to routine billing questions for a human representative to review” is testable.
2. Set a baseline before introducing the tool. Record the current time, cost, error rate, rework, or customer outcome that matters. Without a baseline, a team may confuse novelty or enthusiasm with improvement.
3. Define the boundary and owner. Decide which data may be used, which decisions remain human, how mistakes are escalated, and who is accountable for the pilot. A product vendor can provide controls, but the organization still owns its choices.
4. Run a limited test and inspect exceptions. Use representative cases, not only easy examples. Track where the system is uncertain, incomplete, or wrong, and ask the people who do the work whether the new process helps or adds hidden work.
5. Choose a decision date. Before the pilot begins, set the conditions for expanding, revising, or stopping it. That prevents a trial from becoming permanent simply because it has already consumed time and budget.

This approach echoes De Cremer’s emphasis on strategy and execution while remaining practical for a small team. It also keeps the evaluation honest: the question is not “Can the model do something impressive?” but “Does this implementation improve a clearly defined task without introducing unacceptable costs or risks?”

The cost question cannot be separated from the value question

AI’s economics are changing quickly, but leaders should resist evaluating a project by the headline cost of a subscription or API call alone. A fuller calculation may include data preparation, integration, security review, staff training, ongoing evaluation, human review, and the cost of correcting errors. In some workflows, the most expensive component will not be the model. It may be the time needed to make the surrounding process dependable.

Alphabet’s quarter is a reminder that infrastructure spending can become a strategic bet at very large scale. For a smaller organization, the equivalent decision may be less dramatic but follows the same logic: committing resources today in expectation of future productivity or growth. The reported capex figure should not be treated as proof that the investment will earn a return. Rather, it makes visible why investors and managers ask for evidence of value after an investment is made.

A good pilot therefore tracks both upside and friction. A tool might reduce drafting time yet create more editing work. It might answer routine requests faster but produce occasional high-impact mistakes. It might improve access to information while making it harder for employees to understand where an answer came from. Each result changes the business case. Leadership means being willing to respond to the full picture, not only the metric that makes the project look successful.

• Measure the outcome, not the activity. Count customer issues resolved, time saved after review, or reduction in repeated work, rather than prompts sent or accounts activated.
• Include the people doing the work. Ask employees what the system changes in their day, where it creates extra steps, and what they need to use it responsibly.
• Make the stop condition real. If the pilot misses its target or creates unacceptable risk, pause, redesign, or discontinue it. Sunk cost is not evidence of success.

Responsible use is operational work, not a poster

Governance often sounds abstract until a real system produces a bad result. Stanford HAI’s 2026 AI Index responsible AI chapter reports 362 documented AI incidents in 2025. That number is a count recorded by the AI Incident Database, not a prediction of an individual company’s risk. It is nevertheless a concrete reason to treat testing, escalation, and accountability as part of deployment rather than as paperwork to complete afterward.

For a team adopting AI, responsible use can begin with a few direct questions: What information will the system see? Who can inspect its output? What kinds of errors would matter most? When must a person take over? How will users be told that AI is involved? What happens when the tool is unavailable or its output cannot be verified? The answers should be specific to the task. A brainstorming assistant and a system influencing a financial, legal, medical, or employment decision do not deserve identical safeguards.

The leader’s job is also to communicate uncertainty without either hype or alarmism. If a system is being tested, say so. If a human reviews the output, explain what that review means and what it does not guarantee. If a tool cannot reliably perform a task, define the limit. Clear communication builds a shared understanding across teams and gives people a way to raise concerns before small mistakes become habitual.

De Cremer’s argument, as presented in the publisher’s book description, is that successful AI transformation depends on leaders applying ordinary leadership capabilities to an unfamiliar technology. That is a useful framing because it puts responsibility where it belongs: not solely on engineers, vendors, or individual employees, but on the people who set priorities and decide what the organization will accept.

A reading map for leaders facing the AI investment cycle

Readers can use The AI-Savvy Leader as a prompt for a focused discussion rather than a checklist to follow blindly. Before a team begins a new AI project, ask each participant to write down the business goal, the expected change for employees or customers, the most important risk, and the evidence that would justify scaling. Compare the answers. Disagreement is useful: it reveals where a shared strategy has not yet been formed.

Then map the project as a sequence of decisions: the problem, the data, the tool, the human review, the measurement, and the stop-or-scale point. A mind map is particularly useful here because it makes dependencies visible. If a pilot relies on data that cannot be shared, a review step no one has time to perform, or a success measure no team owns, the map exposes that weakness before more budget is committed.

The bigger lesson from this week’s AI news is not that every company should chase the latest model. It is that model capability, infrastructure, workflow design, and organizational responsibility are now intertwined. A careful leader can be enthusiastic about what new systems might make possible while still requiring a specific problem, a realistic pilot, transparent guardrails, and a clear definition of success.

Key Takeaways

• Alphabet’s October 28 announcement of Gemini 4 Carbon illustrates how frontier-model news is increasingly tied to infrastructure, market, and deployment decisions.
• AI adoption is widespread, but adoption statistics do not demonstrate positive returns or responsible implementation.
• Use a measured pilot: define one job, set a baseline, assign an owner, examine exceptions, and decide in advance when to scale or stop.
• Human review, data boundaries, communication, and accountability belong in the operating plan from the start.
• The AI-Savvy Leader is a useful management read for executives who need to connect AI use to organizational strategy rather than treat technology adoption as the strategy itself.