An AI strategy ends up in a contract

Ask an organisation for its AI strategy and you will usually get one of three documents: a list of tools to be licensed, a statement of values, or a register of twelve pilots and no decisions.

None of them is a strategy. A strategy is a set of decisions about what will be done and what will not, and you can recognise one by what has been left out and by the fact that somebody has said how much money and time will be spent before the thing is judged.

There is a second thing worth saying at the start, because it changes what the document should contain. Almost every organisation writing an AI strategy this year will buy rather than build. That is the right choice for most of them. But strategies are still written in the language of construction, as though the hard questions were technical, and the hard questions are not technical. They are questions about what you are buying, what you are refusing to buy, what you require of the supplier, and when you stop paying.

This piece is organised around six questions. The second one is the one that actually decides the rest.

The six questions

A strategy is finished when these have been answered in writing and the answers are the sort somebody could disagree with. If nobody could disagree with any of them, they are observations rather than answers.

1. What is this for?

There are three respectable motives.

The same work for less. The machine does part of what a person did, or does it faster. What gets measured is time, error rate or cost per unit.

A better product or service. The customer gets something they did not get before, or gets it sooner. What gets measured is the change the customer notices, not internal efficiency.

Something new to sell. A product or service exists that did not exist before. This usually takes the longest, because it also requires pricing, a contract model and a sales motion.

One motive is enough. The mistake is not modesty. The mistake is writing all three into the document because all three sound ambitious, after which none of them gets a measure or an owner.

One answer does not qualify: "adopting AI" is not an objective. It describes activity rather than a result. The same goes for "keeping up with competitors", which does not say what will be done.

2. What do we buy, and what do we refuse to buy?

There are four options: buy, partner, build, or leave undone. The last is the one that goes missing, and it is often correct.

Set the default to buy. This is not surrender. Few organisations write their own accounting software or run their own mail server, and general AI tooling now sits in the same place: a finished product is usually further along than anything your own maintenance capacity can sustain.

There are still respectable reasons to build:

• The thing in question is what your work actually turns on, and it is not for sale.
• No product bends to the integration the work requires.
• Reliability, or where the data sits, sets conditions no supplier meets.

A reason is not sufficient on its own. Ask two more things of anything you build: a demonstrable advantage over the bought version, and a named answer to who maintains it in three years. Without the second, this is not building. It is borrowing.

And if a thing cannot be bought and cannot be afforded, the third option is to leave it undone and write down why. That is a decision like any other.

Note also that "build" rarely means training a model. In practice it means what gets assembled around a finished model: where the information comes from, what instructions it is given, what systems it connects to. That choice is set out in prompting, retrieval or fine-tuning.

3. What do we have to understand about our own work?

This question is asked least often, and it takes two forms depending on whether you compete.

If you compete, the question is about advantage. Models are available to everybody at the same price and a competitor can buy the same one tomorrow, so advantage does not come from the model. It comes from what you have and others do not, which is usually material that accumulates from doing the work and cannot be purchased: fifteen years of your own machines' repair history, or what actually happened during a site visit rather than what was written on the invoice.

If you do not compete, the question is the same without the competitive framing. A council or a charity does not have to justify improvement by pointing at what others lack. The question becomes what has to be understood or organised in your own operation before a tool can produce anything: which members turned up in the past and why, or where people actually get stuck in a service.

The usual obstacle is not that this material is missing. It is that it sits across three systems and is in poor condition. That is a different problem from absence, and generally a solvable one.

If the honest answer is that there is nothing distinctive, that is a finding rather than a failure. It does not follow that the work is done. The first motive, the same work for less, still stands, and reaching it usually requires changing how the work flows, connecting to systems that already exist, and checking afterwards whether anything moved. Buying standard tools is a procurement decision. The strategy is what happens to the work after that.

4. Who owns this?

One named person, not a group. The reason is that accountability does not divide. When five people are responsible for the same thing, nobody is responsible for it on the day it is half finished and something else is more urgent.

The owner is whoever can do three things without taking them anywhere:

• Start. Decide what is picked up next.
• Spend. Within an agreed sum, without separate approval each time.
• Stop. This is the important one and the one most often missing. If stopping requires an executive decision, nothing stops, because nobody wants to carry bad news to that room.

A steering group is useful, but it is a different thing. It is where the owner reports what has happened and where changes of direction are settled. If it is the only body that decides, nothing happens between meetings, and meetings are monthly.

There is an easy test: ask three people who is responsible for this. Three different answers, or the name of a department, means there is no owner.

Writing a name on a page does not make anyone an owner. That starts at the moment something has been taken off their other work. If nothing has been removed, the task is done after everything else, and everything else does not run out.

5. What has to be settled before it goes live?

Four things, and they are cheaper to settle before anything is built.

Use of data. Whether a customer's, member's or employee's information may be used for this particular purpose. A contract clause does not settle it on its own. Processing personal data requires a lawful basis under the GDPR and an assessment of whether the new use fits the purpose the data was collected for. The contract is part of the answer, not the whole of it.

Classification. Where the use falls under the AI Act. The category follows the purpose and the Regulation's own conditions rather than the technology, so the same tool can sit in different categories in different tasks. Assessments about people are where it pays to check first, but checking is work and the outcome is not something to assume in advance.

The human role. Where a person approves the result, and whether they have the time and the information to disagree. The approval point does not by itself determine legal liability, but without it noticing an error is left to chance.

What happens when the answer is wrong. Not if. Who notices, how quickly, and what the fallback is meanwhile.

These are not ethics as a separate chapter. They are conditions of going live. Left open, a finished system sits unused, which costs more than not having built it.

6. How will we know it worked?

Measures reveal whether this is a strategy or a wish list.

These are adoption measures. They are useful for that purpose, because they say whether the rollout is moving, but they do not say whether any benefit appeared:

• How many people use the tool
• How many pilots are running
• How many licences were bought
• What share of staff has been trained

These measure results, because it is possible to lose on them:

• How many working hours a month were freed, against a recorded baseline
• Whether quality held: errors, complaints and rework
• What the total cost is, licences and checking time included
• What share of cases is resolved first time
• How long the customer waits

The middle two are there because hours freed is a misleading figure on its own. If the time spent checking and correcting is not in the same table, the saving looks larger than it is.

One readiness measure is worth keeping despite belonging to the first list: how long it takes from a decision to a team being able to try a new use case safely. It earns its place because it predicts price. If the answer is months, the second use case costs about what the first one did, and nothing accumulates.

What the six questions look like filled in

This is invented. The company does not exist and the figures are illustrative, but the shape is what to aim for.

Example Software Ltd, 45 people, one SaaS product.

1. What it is for. The same work for less. Support answers the same questions repeatedly, and roughly a third of tickets have already been solved somewhere.
2. What we buy. The first case is bought: the ticketing system's own answer assistant. The capability to build exists in house, but it goes into the product rather than into an internal tool. Building is reconsidered only if the bought version will not bend.
3. What we have to understand about our own work. The best answers live in Slack threads and old tickets and have never been written down as guidance. The thirty most common questions get written up first, because otherwise the assistant repeats the old misunderstandings in confident prose.
4. Who owns it. The support team lead. Their on-call shifts move to somebody else, and they have the authority to stop.
5. What has to be settled. Tickets contain customers' personal data, so the lawful basis and the supplier's terms are checked before go-live. The assistant drafts, a person sends.
6. How we will know. First-contact resolution rises, escalations do not, and total cost including licences stays below the value of the time saved. Measured at six months against a three-month baseline.

Resources and the continuation decision. At most 8,000 euros and one person-day a week for six months. Interim review at three months: if first-contact resolution has not moved by then, it stops and the rest of the money goes unspent.

Not this year. A model of our own trained on product data, because there is nothing that needs teaching. Sales call analysis, because call volume does not justify it. Automated code review, because nobody on the team has asked for it.

What changes at a larger scale

The six answers stay the same. Three things change.

The sums and the horizon grow. Tens of thousands rather than thousands, and the interim review moves later, because measuring the baseline alone takes longer when the work is done differently in several units.

The owner sits further from the work. They then have to name somebody beneath them who sees the result daily. Otherwise the decision to stop rests on a report rather than an observation, and a report always says the thing is progressing.

The list of what is not being done gets longer and matters more. In a large organisation ideas arrive faster than anyone can assess them. The value of the page is that it gives permission to say no without inventing the reason afresh each time.

What does not change at any size: one target at a time, a recorded baseline, and a condition on which it stops.

What buying in Europe adds

If the second question is the one that decides the rest, then most of an AI strategy ends up inside a supplier contract. Four things are worth settling before signing rather than afterwards.

Which role you are in. The AI Act divides obligations between a provider and a deployer, and a deployer can become a provider by accident, for instance by putting its own name on a high-risk system or changing substantially what it is for. Our piece on what applies when sets this out. The procurement point is narrower: settle which side of that line the intended use falls on before you sign, because it determines what you have to be able to produce later and who is expected to produce it.

Buying does not transfer accountability. Under data protection law you generally remain the controller of your customers' data and the supplier is a processor acting on your instructions. Outsourcing the work does not outsource the duty, and this is the single most common misunderstanding in AI procurement.

What you can get back out. Ask what logs you can obtain, in what form, and how quickly. If you later have to show what the system did in a particular case, either to a customer or to a regulator, that evidence has to exist and be reachable. It is far cheaper as a clause than as a retrofit.

What happens if the supplier goes away. Or triples the price, or is bought by somebody you would not have chosen. A tool list never asks this. A strategy should, because the answer determines how much of your own work you are willing to rebuild around one vendor.

None of this requires a legal department to start. It requires the questions to be on the table while there is still a negotiation.

Writing it down

What fits on one page is the decisions, not the reasoning behind them. This is worth stating precisely so the promise does not sound too easy: the checks in question five, writing up the tacit knowledge in question three, and measuring the baseline are real work that takes weeks. The one-page document is the output of that work, not a substitute for it.

The first draft can still be written in an afternoon, and it is better written before the checks rather than after. It shows immediately which parts are open, and the work then goes to those parts rather than to everything imaginable.

What belongs on the page:

• Six answers, a few sentences each
• The first target named, not a list of possibilities
• How much money and working time, and by when
• The condition on which it stops
• A date, and when the text gets looked at again. Three months is a workable interval
• A list of what is not being done this year, with a reason for each

The last item is why the document is worth writing at all. Without a list of exclusions a strategy rules nothing out, and then every new idea fits inside it.

Four ways to fail

The pilot that never ends. Trials are cheap, so trials accumulate. Write down in advance what each one has to show and what happens if it shows it. Otherwise a successful pilot leads to another pilot.

A strategy that is a list of tools. Software changes within a year. If the document goes out of date when the supplier does, it was not a strategy.

Adoption as the only measure. Usage tells you about rollout, not about benefit. It can also stay low while the tool is good, if the tool does not fit the work. In either direction the number answers a different question from whether this was worth doing.

No owner. This is the cheapest to fix, because it requires no purchase. It is still not free: ownership means working time taken from something else, and authority taken from somebody else.

In one sentence

An AI strategy is not a list of tools or a statement of values but six answers with a first target, a sum, a deadline and a stopping condition written after them, and since almost all of it will be delivered by somebody you are paying, the decisions that matter most are the ones you make before you sign.

Disclosure

I work in the AI field and advise organisations on these questions, and I have financial interests connected to a company in it, set out on the disclaimer page. This piece is a general description of what an AI strategy consists of. It is not based on any client's material, does not describe any organisation's situation, and is not advice given under an engagement. The passages on data protection and the AI Act are general information rather than legal advice.