# The CTO Role at the AI Frontier

I have spent many years leading technology across sectors and executive roles, including taking a business through a successful exit. I have seen technology change organisations before. I have rarely seen it change the job of leading technology this quickly, and I have never found the job more exciting.

The fundamentals have not changed. A CTO still builds reliable platforms, develops strong teams and translates business ambition into a technical roadmap. What has changed is the size of the opportunity and the speed at which it moves. Problems that were impractical to solve a year ago are now within reach, and the models, tools, risks and economics behind them can shift in a matter of weeks.

I lead technology at a platform serving private equity, private credit and real assets firms. Our clients trust us with some of the most sensitive information in their businesses. So the question is never just "can we?" It is "can we, safely, accurately, and in a way we can defend to a client's compliance team?"

That tension is, to me, what AI leadership is really about: creating genuine advantage, moving quickly without losing control, and earning trust while the technology keeps changing. This piece sets out how I think about each of those.

## AI advantage is a leadership question, not a model question

Every company now has access to the same frontier models. That means the model is rarely the advantage. The advantage comes from everything around it: deep domain understanding, well-governed and connected data, a place in the way people actually work, and the engineering discipline to keep all of it secure, accurate and current while the models underneath keep changing. Accessing a model is easy. Building and sustaining everything around it is the hard part, and it is where specialist platforms, built for a domain and refined across many firms, pull ahead of general-purpose tools and one-off builds.

In private markets, that sits at the intersection of relationships, data and workflows. Firms run on relationships with investors, intermediaries and portfolio companies, and those relationships generate a constant stream of signals that are scattered across systems and largely untapped. Fundraising, diligence and investor servicing are full of work that was always valuable but never practical to do at scale. AI changes that.

The CTO's job is not to bolt AI onto existing features and announce it. It is to understand the domain deeply enough to see where AI changes the economics of a client's work, and then to build the capability, the platform and the trust needed to deliver it. Technology strategy has become product strategy and competitive strategy at the same time. A technology leader who is not part of that conversation is leaving it to others.

## Leading people through the change

AI is not only an engineering story, but it starts there, and how a CTO leads the team through it matters as much as any technical decision.

**For engineers**, the craft is moving from writing code to designing systems that reason. Context design, retrieval quality, tool interfaces and evaluation are now core engineering skills. Judgement matters more than ever, because an agent will confidently produce something plausible and wrong.

**For engineering managers**, the job is deciding where AI genuinely accelerates a team and where it adds review burden, rework and hidden risk. Their quality question has changed from "did it ship?" to "how do we know it behaves correctly across the cases we didn't think of?"

**For executives**, AI has collapsed the distance between technology strategy and business strategy. A CTO who cannot explain model choice, data boundaries and failure modes in plain language to a board, a client or an auditor is leaving a gap someone else will fill.

My role is to make it safe for people to experiment, give them the time and tools to learn, and be clear about the standards that do not bend. Curiosity and rigour have to grow together. A team that has only one of them will either stand still or ship things it cannot stand behind.

## Engineering productivity: measure it honestly

AI-assisted engineering is one of the biggest levers a CTO has. It can shorten delivery, free senior engineers for harder problems and let a team take on work that would previously have needed one twice its size. It is also one of the easiest places to fool yourself.

Generated code arrives quickly. Reviewing it, correcting it and living with it does not. A team that feels faster can be shipping more defects, accumulating more rework and spending more of its senior engineers' time in review. Lines of code and pull request counts will not tell you the difference.

Frameworks such as [DORA](https://dora.dev/) provide a useful starting point for understanding software delivery performance. I look at the question across three dimensions:

*   **Delivery time.** How long work takes from idea to production, not just how long it takes to write.
    
*   **Quality.** Change failure rates, escaped defects and incidents, so speed is not bought with reliability.
    
*   **Cost.** Tooling and model spend alongside engineering time, including the review and rework that AI-generated code creates.
    

Delivery metrics alone do not tell you whether AI is the reason things got better or worse. The value comes from connecting them to how AI is being used across the workflow, so you can see where it genuinely helps and where it simply moves effort somewhere less visible.

## Foundations: AI is only as good as the platform beneath it

It is easy to talk about AI as if it sits apart from everything else. It does not. AI strategy is built on platform strategy.

Agents act through APIs. If your API layer is inconsistent, incomplete or poorly secured, your AI capabilities will be too. Retrieval depends on well-modelled, well-governed data. And AI amplifies whatever reliability you already have: an assistant built on a fragile service becomes a fragile assistant, in front of clients.

That is why I see modernisation, reliability and a clean, well-documented API layer as the foundations of an AI strategy, not competing priorities. Every investment in the core platform increases what AI can safely do on top of it.

## Keeping pace without chasing every release

The release cadence from frontier labs is relentless, and the leaderboard barely holds still. In my experience, the model that leads on a particular task can be overtaken within weeks as rival labs ship something better. Model choice is a moving target, not a one-off procurement decision.

There is a quieter problem too. The largest vendors can become the default choice on the strength of marketing reach and existing enterprise relationships rather than fit. Meanwhile, smaller and specialised models, stronger at a particular task, cheaper to run or deployable closer to your data, go untapped because nobody had the time or mandate to evaluate them. Defaulting to the biggest name feels safe. It is not always a good decision.

The discipline I believe in separates **sensing** from **committing**, and it rests on evaluation. We have made evaluation part of how we deliver software, so changes to AI capabilities have to pass the same quality gates as any other change.

*   **Sense broadly.** Track the landscape and test new options against your own use cases, including specialist and open-weight models (models whose weights are published and can be run on your own infrastructure).
    
*   **Commit narrowly.** Only adopt something when it clears the bar on your own evaluations, not on a vendor's benchmark.
    
*   **Design for change.** Abstract the model layer so swapping or mixing models is a configuration decision, not a rewrite.
    

The goal is not to be first to every release. It is to be the team that can adopt the right one fastest, with confidence it works.

## Working with frontier partners

Very few companies will train their own frontier models, and they shouldn't try. That makes relationships with model providers and cloud providers strategic in a way vendor relationships rarely were before. Done well, these partnerships give you early access, technical guidance and a voice in roadmaps that affect your product. Done badly, they create a dependency you cannot price, audit or exit.

My principles are simple. Partner deeply, but depend carefully: single-vendor lock-in at the model layer is a commercial and operational risk. Know exactly where your data goes, including residency, retention, training opt-outs and sub-processors, and be able to explain it to clients. And treat model changes like dependency upgrades, because a provider updating a model can change your product's behaviour overnight.

## Security and compliance: a new attack surface and a moving rulebook

AI adds an attack surface most security programmes were not designed for.

The [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) keeps prompt injection as its leading risk and moves excessive agency up from sixth to third, as more AI applications are given tools and the authority to act. OWASP's separate [Top 10 for Agentic Applications](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/) goes further for agentic systems, covering goal hijacking, tool misuse and privilege abuse. When a model can only chat, a hidden instruction in a document is embarrassing. When it can call tools, read files and send messages, it is a breach. [EchoLeak (CVE-2025-32711)](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32711), a zero-click vulnerability in Microsoft 365 Copilot where a crafted email could exfiltrate internal content, showed this is not theoretical.

The lessons are blunt:

*   **A system prompt is not a security control.** Authorisation belongs in code and infrastructure, not in instructions to the model.
    
*   **Least privilege applies to agents too.** An agent should see only the data the user in front of it is entitled to see, and act only within that user's permissions.
    
*   **Treat model output as untrusted input.** Validate it before it touches a database, a browser or another system.
    
*   **Make AI visible to your security team.** AI capabilities need the same monitoring as any other system, so security teams can act on suspicious activity, whether it comes from an agent behaving unexpectedly or a person misusing it.
    

Regulation is moving at the same pace. The EU's Digital Omnibus on AI, [Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744), entered into force on 27 July 2026. It moves obligations for stand-alone high-risk AI systems listed in Annex III of the AI Act to 2 December 2027, and for high-risk AI in regulated products under Annex I to 2 August 2028. It would be a mistake to read that as a pause. The existing prohibitions, AI literacy duties, transparency obligations and general-purpose AI model rules were not delayed, new prohibitions apply from 2 December 2026, and in regulated industries clients' own compliance teams are not waiting for deadlines.

For a CTO, compliance is now a design input rather than a sign-off step. Frameworks like [ISO/IEC 42001](https://www.iso.org/standard/81230.html) give a useful structure, but the real work is cultural: making risk assessment, data lineage and documentation part of how AI capabilities are built from day one.

## Building AI people can trust

In private markets, a confidently wrong answer about a fund, an investor or a deal is worse than no answer at all. Accuracy and reliability are not polish to add later. They are the product.

These are the principles I hold every AI capability to:

1.  **Evaluate before you ship.** Every capability needs clear criteria for what good looks like, tested against real, representative cases, and re-tested when anything underneath it changes.
    
2.  **Ground answers in governed data.** For domain-specific answers, retrieval from well-modelled, permissioned and current data is generally more dependable than a model's general knowledge alone. Users should be able to see where an answer came from.
    
3.  **Respect the data boundary.** If a user cannot see a record in the product, the AI must not be able to see it either.
    
4.  **Fail gracefully.** The AI should be able to say "I don't know", and the product should make uncertainty visible rather than hiding it.
    
5.  **Keep humans accountable for consequential actions.** Agents can draft, prepare and recommend. Decisions that matter stay with a person until the evidence says otherwise.
    
6.  **Observe without creating a new risk.** Log enough to investigate failures and detect misuse, but treat those logs as the sensitive data they are: minimise, redact, restrict access and limit retention.
    

None of this is glamorous. All of it is what separates a demo from a platform clients will bet their business on.

## Economics: from cost per outcome to value per outcome

AI spend behaves differently from traditional infrastructure. Usage-based pricing, agent loops that call models many times per task and ever-larger context windows mean costs can scale faster than value, whether you are building a product capability or an internal tool.

One pattern I have seen first-hand is what happens when data grows. Giving AI access to more data can make it far more useful, but only if the retrieval architecture, data quality and evaluation approach scale with it. An AI system designed and proven at a small scale does not automatically hold up as the data behind it grows. Retrieval gets slower and noisier, more context has to be pushed through the model, and the architecture that was efficient at launch struggles with the load. The result is the worst of both worlds: costs that climb sharply while outcomes for users get worse. Designing for the data volumes you expect to have, not the ones you have today, is far cheaper than retrofitting later.

Neglect is the other quiet cost. Something that worked well and cheaply a year ago does not stay that way if nobody maintains it. Model providers deprecate and retire older models, forcing migrations at inconvenient times, while some cloud platforms keep them running at a premium: [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-lifecycle.html), for example, warns customers to expect higher pricing for legacy models during its extended access period. Libraries, SDKs and connectors need patching. And an AI capability nobody is improving does not hold its position; competitors iterating every week will overtake it.

The controls are not complicated: attribute spend to capabilities, teams and customers; set budgets and limits; route work to the cheapest model that passes your evaluations; and give every AI capability an owner and a maintenance budget.

But controlling cost is only half of the picture. Knowing what a capability costs per outcome is the starting point. The real question is what that outcome is worth to the client: the hours a team gets back, the question answered in minutes instead of days, the signal that would otherwise have been missed. A CTO now needs to understand the unit economics of what the business builds, and how cost to serve compares with value delivered. That is no longer a finance question with a technical footnote. It is part of technology leadership.

## What this asks of technology leaders

The modern CTO is part technologist, part strategist, part risk leader and part translator. Beneath all of those sits one constant: accountability, for the advantage we create as much as for the risks we manage.

That means staying close enough to the technology to exercise sound judgement. It means building safety and evaluation into engineering rather than bolting them on afterwards, measuring honestly what AI is changing, and understanding the economics of what we build. And it means being honest about uncertainty, with our teams, our boards and our clients. Nobody has this fully figured out, and pretending otherwise is its own risk.

It also means recognising what a privilege this moment is. Work that would once have taken years of incremental progress is now possible in months. For a technology leader, there has rarely been a better time to build.

The frontier will keep moving. Our job is not to predict exactly where it goes. It is to build teams, platforms and guardrails that let us move with it, quickly and safely, while continuing to earn the trust of the people whose data and decisions depend on what we build.

That, to me, is the defining challenge, and the defining opportunity, of the CTO role at the AI frontier.

I would love to hear from other technology leaders: what has changed most in your role over the last two years?

## Sources

*   [DORA: DevOps Research and Assessment](https://dora.dev/)
    
*   [OWASP GenAI LLM Top 10 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)
    
*   [OWASP Top 10 for LLM Applications 2026 (announcement)](https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/)
    
*   [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/)
    
*   [Microsoft Security Response Center: CVE-2025-32711 (EchoLeak)](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32711)
    
*   [EUR-Lex: Regulation (EU) 2026/1744, Digital Omnibus on AI](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744)
    
*   [ISO/IEC 42001: AI management systems](https://www.iso.org/standard/81230.html)
    
*   [Amazon Bedrock: model lifecycle](https://docs.aws.amazon.com/bedrock/latest/userguide/model-lifecycle.html)