The most expensive mistake in AI content projects is selecting a platform first. It happens because the platform decision feels like progress, is easy to get budget for, and produces a demonstration. The questions that determine whether the investment pays off — what problem this solves, whose content it is, what shape that content is in — are harder and less satisfying, so they get deferred until they become constraints instead of choices.
This article covers the work that should happen before any technology is chosen. It deliberately names no products. Once the decisions here are made, the implementation roadmap picks up where this leaves off.
Start with a business goal, not a capability
"We want to use AI in our content" is not a goal; it is a budget line looking for a justification. Useful goals name a person, a difficulty, and a consequence:
- Customers cannot determine which of our services applies to them, so they call — and often call the wrong team.
- Field staff cannot find the current version of a procedure, so they work from memory.
- Our product information exists in four systems and disagrees with itself, so the website is wrong often enough that people stopped trusting it.
- Six people maintain a policy library, and review has silently fallen behind because the volume outgrew the process.
Each of these implies a different content model, a different retrieval design, and a different definition of success. A goal stated at this resolution does more to shape the project than any platform comparison.
Understand who you are serving
Content strategy fails when it optimises for the organization's structure rather than the audience's questions. Two questions are worth answering explicitly:
- What are people actually trying to do? Site search logs are the cheapest research available and are routinely ignored. Zero-result searches and repeatedly refined queries tell you precisely where your content is failing.
- How do they describe it? The vocabulary gap between organizational language and customer language is one of the main reasons search underperforms. Semantic retrieval narrows the gap; it does not close one that is very wide.
Inventory the content you actually have
Almost every organization is surprised here — by volume, by duplication, and by how much is obsolete. A useful inventory records, for each significant set of content: where it lives, who owns it, when it was last reviewed, whether it duplicates something else, and whether it is accurate today.
That last column is the one that changes plans. Content nobody will vouch for cannot ground an assistant and should not be indexed for retrieval. Deciding what to archive is frequently the highest-value early outcome, and it costs nothing in licensing.
Assign ownership before anything else
Every content set needs a named person accountable for its accuracy — not a department, a person. Unowned content is the root cause of most content problems and cannot be fixed by software, because software cannot decide whether a statement is still true.
This is usually the hardest part of the strategy, and it is organizational rather than technical. It is also the part that determines whether the platform is still trustworthy in two years.
Plan the structure
Structured content is the precondition for reuse, retrieval, and any assistant. Planning it means deciding what your content is, in business terms:
- Content types. A service, a policy, a location, a product, a person, an event — each with its own fields rather than a general "page".
- Relationships. Which service is governed by which policy; which document supersedes which. These relationships carry a lot of the eventual value.
- Granularity. How finely to break content apart. Too coarse and reuse is impossible; too fine and editing becomes miserable. This is a judgement call with real consequences either way.
Taxonomy and metadata
A taxonomy is a controlled vocabulary the organization agrees to use consistently. Design it around how people search, keep it as small as it can be while remaining useful, and define what each term means so that two editors make the same choice. Over-elaborate taxonomies are abandoned; the failure is almost always ambition rather than negligence.
That definition work also determines whether automatic classification can succeed later: a vocabulary two experienced people would apply differently cannot be applied consistently by a system either.
Identify the source systems
Content relevant to a customer's or employee's question rarely lives in one place. Map the systems that hold it — document repositories, intranets, CRM, ERP, product databases — and for each, establish whether it can be read programmatically, whether its permission model can be honoured, and who authorises access.
That third question routinely takes longer than the integration itself, and it belongs in the strategy phase rather than being discovered mid-build.
Define the search requirement
"Better search" is not a requirement. A requirement looks like: staff must be able to ask a natural-language question and receive an answer drawn only from current, approved procedures they are permitted to see, with a link to the source. That statement determines the retrieval architecture, the permission model, and the acceptance test all at once.
Set security and permission expectations early
Two questions shape the architecture more than any other, and both must be answered before selection:
- Where may this content be processed? Some organizations can use hosted model providers freely; others have data-residency or contractual constraints that rule them out for particular content. This determines the entire provider shortlist.
- How are permissions enforced at retrieval? If a system can retrieve content to answer a question, it can leak content. Permission-aware retrieval is a design requirement, not a configuration option added later.
These sit alongside the wider security posture LABUSA addresses through managed IT and cybersecurity services, and in regulated environments they should be settled with the people accountable for that posture in the room.
Decide the AI governance position
Before implementation, the organization should be able to state: where AI may be used and where it may not; who reviews AI-assisted content before publication; how AI involvement is recorded; who is accountable when something is wrong; and how model changes are monitored. Writing this down early is far easier than retrofitting it after an incident, and AI content governance covers how each of those positions is actually established and evidenced.
Build versus buy
Rarely a binary. Most implementations combine a bought CMS, bought AI services, and built integration and content modelling. The judgement is about where differentiation actually lies:
- Buy commodity capability — the CMS itself, model access, search infrastructure.
- Build what is specific to your content, your systems, and your rules — the content model, the integrations, the governance.
- Be cautious about buying an end-to-end product that assumes a content model you have not designed. It will fit some of your content and quietly distort the rest.
Keeping the CMS, retrieval layer, and model provider separable is worth a small amount of extra design effort, because it is what allows any one of them to be replaced later without rebuilding the platform. Once the requirements here are settled, how to choose an AI CMS solution covers the selection itself.
Sequence the roadmap
A workable sequence, without committing to durations that depend on your organization:
- Assess — inventory, ownership, search logs, systems, constraints.
- Prepare — archive what is obsolete, fix what is wrong, agree the taxonomy.
- Model — define content types and relationships.
- Improve retrieval — better search on prepared content. Often delivers visible value before any AI feature.
- Add assistance — editorial tooling where it saves real effort.
- Consider assistants — once the content beneath them is trustworthy.
Each stage delivers something on its own. That property matters: it means the programme can be paused or stopped without having produced nothing.
Define success measures now
Choose measures before implementation and capture a baseline, or you will be unable to demonstrate improvement afterwards. Observable candidates include search success rate, proportion of zero-result searches, self-service completion, editorial cycle time, share of content within its review period, and content reuse across channels. Avoid committing to financial-return figures that depend on assumptions nobody has validated.
Working through this for your organization? Discuss your content strategy with LABUSA — the assessment is a much smaller undertaking than the implementation, and it is what makes the implementation predictable.
How LABUSA approaches strategy work
We begin with content and questions rather than platforms. That means reviewing what you have, what people are failing to find, which systems hold the rest, and what your security posture permits — then recommending an approach, which sometimes means recommending less technology than expected.
Because our AI CMS solutions practice sits alongside enterprise architecture, integration, and security work, strategy recommendations account for what it will take to operate the result, not only to build it. Where the wider technology strategy is also in question, IT consulting in the era of AI covers that broader ground, and our IT consulting capability describes how we engage.
Frequently asked questions
How long should strategy take before implementation starts?
It varies with content volume and how many systems are involved, but it is materially shorter than the implementation. The failure mode is skipping it, not over-investing in it.
Who should be involved?
Content owners, an IT or architecture representative, someone accountable for security or compliance, and a sponsor able to settle ownership disputes. That last role is the one most often missing.
What if content ownership is genuinely unclear?
Then establishing it is the first deliverable. It is uncomfortable, and no technology decision made before it is resolved will hold.
Do we need a taxonomy before we start?
You need a draft. Taxonomies improve through use, but starting without one means inconsistency is designed in from the first day.
Can strategy work be done internally?
Often, yes, and where the capability exists it should be. External help is most useful for the content model, the retrieval design, and challenging assumptions that have gone unexamined internally.
Related reading
- How to Implement an AI-Powered CMS — what happens after the strategy is agreed.
- AI CMS vs. Traditional CMS — whether to change platform at all.
- What Is an AI-Powered CMS? — the capabilities a strategy is planning for.
- IT Consulting in the Era of AI — AI's effect on technology strategy generally.