CTO — Charter

The CTO owns the technology position: what we build, what we buy, what we run, and whether any of it will still be maintainable in three years.

In an AI-operated company one decision dominates the rest, and most organisations get it wrong in the same direction: how much AI capability to build versus buy. The instinct to build is usually about wanting to own the capability rather than about economics.

What this role owns#

Technology strategy. Which platforms, which languages, which providers — and the discipline of having few of each.

Architecture authority. The decisions that are expensive to change: how systems are split, how they communicate, where state lives, and the consistency model.

Build versus buy. Including the honest version, where "we could build this" and "we should build this" are different questions.

AI capability. Which models, which providers, what runs in-house, and what data leaves the organisation.

Technical risk. Concentration on one supplier, key-person dependency, accumulated debt, and end-of-life technology.

KPIs#

Build versus buy, honestly#

A usable order of preference:

1. Use what is already in your tools. Your existing platforms increasingly include AI. Zero integration, no project.
2. Buy a specialist product. Someone has solved document processing or support triage for your sector already, and almost certainly cheaper than you will.
3. Build on a model API. Justified when the problem is specific to how your business works.
4. Train your own model. Almost never right. Reserve it for cases where a general model genuinely cannot do the job and you have large volumes of proprietary data.

Most organisations should exhaust 1 and 2 before considering 3. The question to ask of any proprietary dependency: if this vanished, how long to replace it?

AI agents in this function#

Architecture review assistant — checks proposed designs against recorded standards and past decisions, and surfaces where this contradicts something already settled.

Technology radar agent — tracks what is emerging, what is maturing and what is being abandoned, with sources.

Cost attribution agent — breaks AI and infrastructure spend down by system and by outcome.

Dependency risk scanner — end-of-life versions, unmaintained libraries, single-supplier concentration.

What stays human: architecture decisions themselves, supplier selection, and any decision that is expensive to reverse. An agent that recommends an architecture is useful; one that chooses it is a governance failure.

SOPs#

• Architecture decision records — what was decided, what was rejected, and why. The rejected options are the valuable part six months later.
• Technology introduction — nothing new enters the estate without an owner, an exit path and a reason the existing option does not work.
• AI system approval — before it goes live: owner, declared tools, permissions, what it can and cannot decide, and how it is evaluated.
• Quarterly debt review — with the cost expressed in delivery capacity, not in engineering complaints.
• Model change protocol — a model upgrade is a change requiring a full evaluation run before it ships.

Templates#

Architecture Diagram Set · Security Checklist · architecture decision record · technology assessment.

Depth in Architecture, Enterprise Architecture and Cloud.

Workflows#

In: capability requests from the business · architecture proposals · security findings · cost reports · supplier changes.

Out: architecture decisions · technology standards · build/buy determinations · risk positions to the CEO.

Handoffs: Engineering for implementation · Security for review · Finance for spend · CEO for anything strategic or irreversible.

FAQ#

Should we build our own AI models?#

Almost certainly not. Training is expensive, needs specialist skill and large proprietary datasets, and general models improve faster than you can retrain. Build the layer that encodes how your business works; buy the intelligence underneath.

How do we avoid lock-in?#

Manage it rather than fear it. Keep your data portable and exportable, keep prompts and evaluation suites provider-agnostic, and accept dependence where the productivity genuinely justifies it. Make it a decision, not an accident.

Who should decide architecture?#

Someone who still has to live with the result. When the person choosing never has to operate what they chose, the choices get cleaner on paper and worse in production.

How much technical debt is acceptable?#

Enough that you shipped, little enough that a simple change stays simple. The signal to act is when routine changes start attracting surprising estimates — that is the estate telling you it has started winning.

What else is coming for CTO