Five Moves Every CTO Should Make Before 2027

AI automates activity. The CTO remains accountable for consequences.

In the last year, I have had the same conversation about AI with three very different technology leaders. They could not have disagreed more.

The first, a CEO I respect, does not trust it. He will not let his engineering team near AI for anything production-grade. He sees the security exposure and the danger of outsourcing human judgment, and has decided the downside is not worth it. He is not being unserious. He is being careful.

The second had gone the other way. They built genuinely capable AI into their product. It worked. But the client it was built for never really used it. The capability was real. The value was immeasurable, because building the feature and getting people to adopt it turned out to be two different problems.

The third, a CTO, uses AI carefully to speed up his delivery, and it helps. But in his product, it is the machine-learning features generating the real ROI, more than the agentic AI features. He is not chasing what is fashionable. He is shipping what delivers.

” Three serious leaders. Three opposite conclusions. All defensible.”

Here is what struck me. The sceptic and the adopter were closer than they looked. Neither could tell me, with evidence, whether AI was actually delivering value. One assumed it would not. The other assumed it had. Neither could measure it.

That is the real state of AI in 2026. The question is no longer whether to adopt it. It is whether anyone can identify where it genuinely creates value, and prove it.

And that is where the CTO role is quietly, permanently changing.

Where is AI actually earning its keep?

AI’s value is showing up, but not where the headlines point.

Everyone talks about AI writing new code. In our own delivery, the bigger unlock has been the opposite: modernizing the old code nobody wanted to touch, the legacy migrations teams postpone for years. Oracle Forms to Java. Informatica to AWS Glue. Ageing systems, thin documentation, original authors long gone. These used to be too risky and too expensive to justify. With agentic tooling across the SDLC and the right expertise, that calculus changed. CTOs who refused these migrations for years are now going ahead — not because the work became fashionable, but because it became viable. (We cover the technical side of this shift in AI in DevSecOps and AI + ML with CI/CD.)

The second shift is in how CTOs buy. The old default was to license a full product and use a fraction of it. Now, with AI lowering the cost of building, more are choosing to build only the few features they need and save the rest. The make-versus-buy line is moving toward lean.

Both are measurable. A migration that ships is measurable. A product you built instead of licensed has a cost you can name. AI’s value becomes real precisely when you can measure it, and vague exactly when you cannot.

The playbook: five moves before 2027

Each move follows the same shape: the situation I keep seeing, the principle behind it, and how to start.

Move 1: Bring AI into the Operating Model

The situation: Go back to 2025. Our people were already using AI. ChatGPT, Claude, pasting code in, getting solutions back, solving real problems. It helped them. But it was not an operating model. It was individual, unofficial, outside any control, which made it a security concern too. The usage was there. The visibility and governance were not.

The principle: AI is almost certainly already inside your team, sanctioned or not. When it lives in the gaps, you get all the risk and none of the visibility.

How to start:

• Make the sanctioned path the better path: move from personal tools to proper team licences.
• Share projects across the team, rather than letting knowledge sit in one person’s chat history.
• Treat AI skill as a primary asset, not a private one. When one engineer learns to get better output, capture and spread it.

The goal is simple: No AI usage you cannot see, and no hard-won skill trapped in one person’s head.

Move 2: Govern at the Point of Use

The situation: We had a strong governance document. Thorough. But it was not changing behaviour. So we ran a programme: everyone read it weekly, and we would randomly ask someone in the daily meeting to talk through a section. It worked halfway. Awareness went up. Usage did not. In the moment of the work, under pressure, a twelve-page document is not in the room.

The principle: A policy creates awareness. It does not create governance. The control has to live at the point of use, inside the tools and the pipeline, not in a document people have read but do not consult while they work.

How to start: Move the control from the document into the workflow. The change that worked for us was enforcement at the moment of action. For example, using CloudByte PMS, if a developer includes PII in a prompt, the prompt is blocked before it reaches the model and a notification is raised. The engineer does not have to remember the rule. The system applies it.

• Enforce data classification at the input layer.
• Log AI access through a gateway so review is automatic.
• Build human review into the pipeline for high-stakes outputs.

The test is simple: does the system prevent the failure, or merely help someone detect it afterwards?

Move 3: Redesign Roles Around Judgment

The situation: The clearest change I have seen in my own organisation is not that AI replaced anyone. It is that it quietly rewrote what every role does.

Take the project manager. He used to run status meetings to find out where things stood. Now the dashboard tells him in real time, freeing him for the work that needs a human: spotting which developer is stuck, noticing when someone has re-prompted the same problem five times, seeing which skills actually drive productivity. He moved from collecting information to acting on it early.

The same ran through every role. The tech lead spends less time hand-holding juniors through problems that AI now helps them solve, and more time on what only he can do: raising standards, hardening security, and lifting the team’s skill. The architect moved further forward, away from the immediate build toward the questions that now decide everything: which model delivers the best return, how to route between models, whether to build local LLMs, whether a project-specific RAG or an autonomous agent is the right answer. And new roles appeared that the old hierarchy never had: prompt engineers, context engineers, AI engineers.

The principle: AI did not flatten the organisation. It redefined every layer. The common thread runs through all of them: the routine activity moved to AI, and the judgment moved up.

I no longer ask my project managers, scrum masters, or project leads for data. AI delivers that faster and more accurately. I rely on them for judgment, influence, and leadership under pressure. AI took the reporting. It gave back the leadership.

How to start: Go through your roles one by one and separate the activity from the judgment. The gathering, formatting, and reporting are what you route to AI. The judgment, standards, foresight, and leadership are what you invest in and grow. Then be honest about the new roles you now need. The mistake is to see AI absorbing the activity and conclude you need fewer people. The truth is you need the same people doing the harder half of their jobs, and some genuinely new ones. Do not hollow out the judgment you will need to govern the machine. Deepen it.

Move 4: Measure Enterprise Flow, Not Activity

The situation: On one of our migration projects, we did everything right. We licensed the right tools, ran a proper training and certification programme, put an experienced team on it. Progress looked good. So we asked the obvious question: how much productivity did we actually gain for the licence fees? The answer came back confident and consistent. Twenty to thirty percent. But when we pressed, it was intuition. A feeling shared across the team, not a number anyone had measured. Everyone believed it. Nobody could prove it.

The principle: A feeling is not a measurement, and by 2027 a feeling will not be enough. Track whether AI improves lead time, release quality, customer value, and cost, not code volume or a sense that things are faster.

How to start: Replace intuition with instrumentation. Track the DORA metrics- lead time, deployment frequency, change failure rate, time to restore- before and after AI adoption, so the productivity claim becomes a measured fact. Then go further than the numbers. Our real gains came not just from the tools, but from measuring which people had genuinely built AI skill and deliberately spreading it across the team, structured transfer, not osmosis. The intuition told us we were twenty percent faster. The measurement told us where we actually were, and what to fix to go further. This single discipline separates the leaders who can prove AI’s value from the ones who can only assume it.

Move 5: Build Strategic Resilience

The situation: I will be honest about my own concerns, because many leaders share them and few say them aloud.

• The economics are not real yet: Many AI companies run on funding, pricing tokens below cost to win the market. The price you pay today is not the price the market will settle on.
• The dependency runs deeper than cost: Engineers who came up in the last year, leaning heavily on AI coding tools, can become productive without ever developing the real feel for programming underneath. If the tool changes, the capability to work without it may not be there.
• The ownership question: The proprietary research and features we build increasingly pass through someone else’s model. Where I cannot fully verify what happens to that data, I plan as if the risk is real.

The principle: Avoid over-dependence on any single model, provider, price, or workflow, and on the tool itself as a substitute for capability. A dependency you cannot exit is a risk, whether commercial, technical, or human.

How to start: Treat your AI supply chain like any critical dependency. Know how much of your capability and your cost base rests on providers you do not control, and model what a significant price rise would do to you. Keep your architecture model-agnostic where you can, so switching is a configuration change, not a rewrite. Protect the underlying skill; make sure your engineers can still reason without the tool, because that is your real insurance. And for anything genuinely proprietary, be deliberate about what leaves your walls. Do not take the luxury of today’s tools, or today’s prices, for granted.

Read Also: AI in Production: The Realities Nobody Talks About

The Closing Thought

The CTO role is not becoming easier or harder. It is becoming deeper.

It will take the reporting, the documentation, the routine analysis, the repetitive build. What remains is the work technology leaders were always ultimately responsible for: judgment, governance, architecture, organizational capability, and trust.

Bring AI into the operating model. Govern at the point of use. Redesign roles around judgment. Measure enterprise flow. Build strategic resilience.

The three leaders I opened with will each be proven partly right. The sceptic, that unmanaged AI is a real risk. The adopter, that the capability is real. The pragmatist, that the value is in the fit, not the fashion. What none of them had was the thing that resolves all three: the ability to measure what AI actually delivers.

That measurement is the CTO’s new job. The ones who build it now will not spend 2027 reacting to change. They will enter it with an operating model already built for it.

FAQs

1. What does an “AI operating model” actually mean for a CTO?

Answer: It means treating AI the way you would any other critical system: sanctioned tooling instead of personal accounts, shared context instead of one person’s chat history, visible usage instead of shadow adoption, and a defined path for spreading AI skill across the team rather than leaving it with whoever picked it up first.

2. How is governing AI “at the point of use” different from a governance policy?

Answer: A policy document creates awareness; people read it, then go back to work under pressure and can’t consult it in the moment. Point-of-use governance puts the control inside the tool or pipeline itself, so the system prevents a failure (like a prompt containing PII reaching a model) instead of merely helping someone detect it afterward.

3. How should engineering teams measure AI’s actual ROI?

Answer: Replace intuition with instrumentation: track the four DORA metrics, lead time, deployment frequency, change failure rate, time to restore, before and after AI adoption, alongside which engineers have genuinely built AI skill and how that skill is spreading. Code volume and a general sense of “feeling faster” are not reliable measures.

4. Does AI adoption mean CTOs need fewer engineers?

Answer: No, it means the same people need to spend more time on judgment, standards, and leadership, and some genuinely new roles (prompt engineers, context engineers, AI engineers) are needed. The routine activity moves to AI; the judgment has to be deepened, not hollowed out.

5. What’s the biggest risk in over-relying on a single AI model or provider?

Answer: Three risks compound: the pricing you see today is often subsidized and won’t hold; engineers who lean entirely on one tool may not develop the underlying skill to work without it; and proprietary data or code passing through a third-party model raises ownership and security questions you can’t fully verify. The fix is a model-agnostic architecture and protecting the human skill underneath the tooling.