How Do You Train AI With the Data the Enterprise Collected?
This article may sound technical, but it is not intended to be a technical specification. It is a mechanical mental model for executives who want to understand what happens to the knowledge their enterprise collects, how AI can use it, what fine-tuning actually changes, and what they should expect from an AI integrator.
In the first article in this series, we looked at the guardrails a company needs before AI can be used safely at scale.
In the second, we looked at a different problem. Much of what an organisation knows is never properly captured. The reasoning behind decisions disappears from meetings, conversations and everyday work.
The argument was that we should not ask employees to stop working so they can document everything for AI. We should change the working environment so that useful organisational knowledge is captured as a by-product of normal work.
Now suppose you have done that.
You have business data, meeting transcripts, discussions, decisions, the reasoning behind them and, where possible, the eventual outcomes.
You have captured how your organisation thinks.
The obvious next question is:
How do you train AI with all of this?
That question quickly leads to technical terms such as embeddings, vector databases, RAG, knowledge graphs, GraphRAG, CAG and fine-tuning.
If you are a CEO or senior executive, you do not need to know how to build these technologies.
But if you are hiring someone to build an AI system around your company’s knowledge, you should understand what the major components do, how they fit together and why you might need them.
First, what do we mean by training our enterprise AI?
When an executive says, “We need to train AI on our company,” they may simply mean:
I want AI to understand our company well enough to work with our information and the way we make decisions.
Technically, accomplishing that does not necessarily mean training the AI model itself.
Most companies can start with an existing AI model and build a company-specific knowledge system around it.
Suppose the organisation has captured 10,000 previous business decisions.
For each decision, it may have some combination of the business data available at the time, alternatives considered, the decision itself, the reasoning behind it and what eventually happened.
When AI encounters a new problem, the company wants it to be able to find the previous knowledge relevant to that situation and use it.
The basic mechanical process is:
Captured enterprise knowledge → prepare it → organise it so it can be found → retrieve what matters → give it to AI → AI uses it
Let’s follow what happens to the knowledge.
First, prepare the captured knowledge
Imagine one of the records captured in Article 2 is a two-hour management meeting.
The transcript contains 20,000 words covering five subjects.
If AI later needs to understand why Product A was retained, it may not be useful to treat the entire meeting as one indivisible piece of information.
One common technique is to divide the material into smaller useful pieces.
This is called chunking.
One chunk might contain the discussion about Product A.
We can then attach information describing it:
Product: Product A
Meeting: Management Committee
Date: 12 March 2026
Subject: Product retention
Decision: Retain for six months
This descriptive information is metadata.
The distinction is straightforward:
Chunking divides information into useful pieces.
Metadata describes those pieces.
Neither, however, tells the system which piece will be useful when somebody asks a new question.
We now need a way to find it.
Embeddings help us find information by meaning
Suppose someone asks:
Should we discontinue Product A?
Somewhere in the company’s accumulated knowledge, an executive previously said:
The economics no longer justify keeping Product A in the portfolio.
A salesperson wrote:
Demand has fallen to a level where I don’t think we should carry it next year.
And an earlier management discussion concluded:
Unless volumes recover, the product no longer has a viable future.
None uses the word discontinue.
A keyword search looking specifically for that word could therefore miss them, even though they are relevant to the question.
This is one reason embeddings are useful.
An embedding represents the meaning of a piece of information numerically.
You do not need to understand the mathematics to understand what this enables.
It allows a computer to compare pieces of information according to their semantic similarity rather than only whether they contain the same words.
So:
Keyword search finds matching words.
Semantic search can find similar meaning.
Embeddings are what make that kind of vector-based semantic comparison possible.
This does not mean semantic search replaces keyword search. Enterprise retrieval systems frequently combine vector, keyword and other search techniques because they are useful for different kinds of questions.
Where does the vector database fit?
Once we create embeddings, those numerical representations need to be indexed somewhere so they can be searched.
This is where you encounter vector search and vector databases.
The terms are related, but they do not mean the same thing.
Embedding is the numerical representation of meaning.
Vector search compares those representations to find similar information.
A vector database, or another search system with vector capabilities, stores and indexes those vectors so they can be searched efficiently.
The vector layer can therefore become part of the enterprise’s organisational-memory system.
The original source may still be a meeting transcript in Microsoft 365, a policy document, a customer record or a decision stored elsewhere. The vector index helps the AI system locate relevant pieces of that knowledge.
Some implementations also store the corresponding text and metadata alongside the vectors. The important mental model is that the vector layer creates a searchable semantic index into the enterprise’s knowledge.
But similarity of meaning is only one way information can be connected.
Some knowledge is related, not merely similar
Return to Product A.
Suppose the company knows:
Product A is sold primarily to Customer B.
Customer B’s account is managed by Division C.
Management Decision D retained Product A for six months.
Decision D depended partly on Customer B being expected to renew its contract.
Customer B subsequently decided not to renew.
The importance of these facts does not come from the sentences having similar meanings.
It comes from their relationships.
This is where a knowledge graph can become useful.
A knowledge graph represents important things and the relationships between them.
For example:
Product A → purchased by → Customer B
Product A → subject of → Decision D
Decision D → depended on → Contract Renewal
Contract Renewal → associated with → Customer B
This should sound familiar from Article 2.
There, I described an organisational decision thread: keeping the company’s thinking about an important subject connected across meetings, conversations, documents and time.
A knowledge graph is one technical way some of those connections can be represented.
So there is another useful distinction:
Vector search helps find information with similar meaning.
A knowledge graph represents information connected through relationships.
They are not necessarily alternatives.
A company may use both.
Now RAG becomes easier to understand
We have captured the knowledge.
We have prepared it.
We have created ways of finding information through words, meaning and, where necessary, relationships.
Now someone asks:
Should we discontinue Product A?
The AI model does not need the company’s entire organisational memory dumped into the conversation.
It needs the relevant parts.
This is where RAG, or Retrieval-Augmented Generation, comes in.
In simplified form:
Employee asks a question
↓
The system searches approved enterprise knowledge
↓
Relevant information is retrieved
↓
That information is placed into the AI’s context
↓
AI uses it to produce its response
Context is simply the information available to the model while it is working on that particular request.
So RAG is not another database, an embedding, a vector search, or another AI model.
RAG is the process of retrieving relevant external knowledge and providing it to the model as context before it generates its response.
The retrieval itself might use keywords, metadata, vector search, a knowledge graph, or combinations of them.
This is how the components begin to add up.
Where does GraphRAG fit?
Sometimes finding individual pieces of information by keywords or semantic similarity is not enough.
The answer may depend on relationships between customers, products, people, decisions and events.
GraphRAG brings those graph relationships into the retrieval process.
Using our example, the system might identify an earlier Product A decision not merely because its wording resembles the current question, but because that decision is connected to Customer B and to the contract renewal that influenced the original decision.
The distinction is:
RAG retrieves relevant information to give to AI.
GraphRAG uses graph relationships as part of finding and assembling that relevant information.
GraphRAG is therefore not automatically a better RAG.
If the questions the company needs AI to answer depend heavily on relationships spread across organisational knowledge, graph-based retrieval may add value.
If they do not, it may introduce complexity the company does not need.
And where does CAG fit?
You may also encounter CAG, usually meaning Cache-Augmented Generation.
It addresses another variation of the same problem.
RAG finds relevant knowledge when it is needed.
But imagine an AI application repeatedly needs the same relatively small and stable body of information. For example, the HR travel policy, the CS standard response manual, or the HVAC maintenance manual.
Instead of repeatedly retrieving it, there are architectures in which that knowledge can be kept readily available in the model’s context or cache for reuse. Conceptually, it is like keeping a document on the desk rather than filing it away in the filing cabinet.
That is the basic idea behind CAG.
For our mental model:
RAG retrieves the relevant knowledge when it is needed.
CAG keeps a suitable body of knowledge readily available for repeated use.
CAG is a newer and less established term than RAG. An executive does not need to decide which acronym to buy.
If an integrator recommends it, the useful question is:
Which knowledge are you proposing to keep readily available, and why is that better than retrieving it when required?
Put the enterprise-knowledge path together
We can now return to the knowledge captured in Article 2.
One possible path through the machinery looks like this:
Captured enterprise knowledge → chunking and metadata → embeddings → vector search/index → knowledge graph where needed → RAG/GraphRAG/CAG → context → AI uses the relevant knowledge
Not every enterprise application will need every component.
That is important.
A knowledge graph is not something every company must build. GraphRAG is not a compulsory upgrade to RAG. A dedicated vector database may not be necessary if existing infrastructure already provides the required capabilities.
The architecture should follow the problem.
But everything we have discussed so far has one thing in common.
We have been making enterprise knowledge available to an existing AI model without changing the model itself.
That brings us to something different.
What is fine-tuning?
Fine-tuning is frequently mentioned alongside RAG, which makes it easy to assume they are alternative ways of doing the same thing.
They are not.
With the knowledge system we have just described, the enterprise’s knowledge remains outside the model.
When AI needs something, the system finds the relevant information and provides it as context.
Fine-tuning changes the model itself through additional training.
Suppose the company has developed a particular way of evaluating whether a product should be retained.
It may consistently consider customer dependency, strategic importance, contribution margin, contractual consequences and several defined risk factors.
Over time, the enterprise may have accumulated many good examples of its experts performing this analysis.
The company could select suitable examples and turn them into training examples showing, conceptually:
Here was the input → here is the kind of output we wanted.
During fine-tuning, those examples are used in an additional training process that adjusts the model’s internal parameters. The objective is to make the model more likely to reproduce the patterns demonstrated by those examples when it encounters similar tasks later.
That is very different from asking the model to retrieve a Product A document.
Is the data used for fine-tuning different?
This is where the relationship with Article 2 becomes particularly important.
The starting source can be the same captured enterprise knowledge.
The Product A meeting, decision, reasoning and outcome might become part of the organisational memory available through retrieval.
But perhaps it is also an exceptionally good example of how the company wants a product-retention analysis performed.
The company might therefore select it, together with many other good examples, and prepare those examples as a fine-tuning dataset.
The source knowledge can be the same.
What changes is what we do with it.
For the enterprise-knowledge system, we prepare information so AI can find and use what the company knows.
For fine-tuning, we select and prepare examples so the model can learn a pattern of how we want a task performed.
That gives us two paths beginning from the same place:
Captured enterprise knowledge
From there:
Path 1 — Make enterprise knowledge available to AI
Prepare → organise and index → retrieve → context → AI uses it
And:
Path 2 — Fine-tune the model
Select suitable examples → prepare training examples → fine-tune → test on unseen examples → evaluate
The same reservoir of organisational knowledge can therefore potentially support both.
But it is prepared differently because it is being used for different purposes.
How do you actually fine-tune the model?
Conceptually, you begin by selecting good examples of the task performed in the way you want it performed.
Those examples have to be prepared into the training format required by the model and fine-tuning system. At its simplest, the model is being shown repeated examples of the relationship between an input and the desired output.
The additional training process adjusts the model so that the demonstrated pattern becomes more likely to appear when it encounters similar inputs in the future.
But training is not the end of the process.
The fine-tuned model then needs to be tested on examples it did not see during fine-tuning.
Did it actually improve?
Does it generalise to new cases?
Does it perform the task reliably enough?
Did the fine-tuning cause undesirable changes elsewhere?
If it does not perform better, the training examples, their quality, the training approach or even the decision to fine-tune may need to be reconsidered.
Fine-tuning therefore does not remove the need for evaluation.
Neither does RAG.
A retrieval system can retrieve the wrong information. A model can misunderstand good retrieved information. A fine-tuned model can learn an undesirable pattern.
Both systems need to be tested against the outcomes the business actually cares about.
The two paths can work together
Now the distinction becomes useful rather than merely technical.
Suppose the company fine-tunes a model to become better at performing its particular product-retention analysis.
The model still needs to know today’s sales, the latest Customer B contract status, what management decided six months ago and what has changed since then.
That current company knowledge does not have to be baked into the model through fine-tuning.
It can be retrieved when needed.
So the two approaches can work together:
Fine-tuning can help teach the model a specialised pattern for performing the task.
Retrieval can provide the current enterprise knowledge required to perform that task today.
This does not mean every enterprise should fine-tune its model.
It is not the final stage of becoming AI-first.
A company may build an excellent enterprise AI application using retrieval and never need fine-tuning.
The question is always what business problem the additional training is intended to solve.
Who actually builds this?
Throughout this article I have referred to an AI integrator.
That deserves an explanation.
I use the term to mean the person or team responsible for translating the company’s business requirement into a working enterprise AI system.
They are not simply someone who knows how to use ChatGPT or write good prompts.
Depending on the project, they may need expertise in AI models, enterprise data, APIs and system integration, databases and search, RAG, security and permissions, evaluation, monitoring and deployment.
But technical knowledge alone is not enough for the kind of project we have been discussing.
The integrator needs to understand the business problem sufficiently well to translate it into a technical architecture.
That does not mean the integrator needs to arrive knowing your business better than you do.
The company’s domain experts still have to explain how decisions are made, what information matters, which exceptions matter, what a good result looks like and where humans must remain responsible.
The relationship should therefore look something like this:
Business leaders and domain experts define the problem, the knowledge, the boundaries and what good looks like.
The AI integrator translates those requirements into the technical system that allows AI to work within them.
For a narrow technical integration, the integrator may primarily be an engineer or architect.
For a broader AI transformation involving workflows, governance, organisational change and decision-making, the project may require a team combining technical integration with business analysis and change-management capabilities.
The title matters less than whether the required capabilities are present.
Before you talk to your AI integrator
You do not need to walk into that meeting knowing how to build a vector database or fine-tune a model.
But after understanding the machinery, you should be able to ask better questions.
Where will our enterprise knowledge come from?
How will you prepare it so AI can use it?
How will the system find the right information when an employee asks a question?
Are you searching by keywords, meaning, relationships, or some combination?
Why are you proposing a vector database?
Do our business relationships justify building a knowledge graph?
Why do we need GraphRAG rather than a simpler retrieval system?
How will RAG decide what information enters the model’s context?
How will our existing data permissions determine what the system is allowed to retrieve?
Can we see which enterprise information the AI used to produce an important answer or recommendation?
How will you test whether retrieval is finding the right information?
Are you proposing fine-tuning?
If so, what are you trying to teach the model?
Which examples will you use?
Why is fine-tuning preferable to providing the model with instructions, examples and retrieved company knowledge at runtime?
And how will we determine whether the fine-tuned model actually performs better on cases it has never seen?
These are not questions about how to write code.
They are management questions about what happens to the enterprise’s accumulated knowledge and how AI will be allowed to use it.
The first article in this series was about controlling what AI is allowed to know and do.
The second was about capturing the organisational intelligence companies currently lose.
This third step is about what happens captured enterprise knowledge can be organised so AI can retrieve and use it.
Selected examples from that same knowledge can, where there is a good reason, be used to fine-tune the model itself.
Those are different mechanisms, but they can begin with the same organisational knowledge and ultimately work together.
Once you can picture that machinery, terms such as embeddings, vector databases, RAG, GraphRAG and fine-tuning stop being a list of AI buzzwords and become components you can place in your mental map and ask what your enterprise actually needs.
How Do You Train AI With the Data the Enterprise Collected?
This article may sound technical, but it is not intended to be a technical specification. It is a mechanical mental model for executives who want to understand what happens to the knowledge their enterprise collects, how AI can use it, what fine-tuning actually changes, and what they should expect from an AI integrator.
In the first article in this series, we looked at the guardrails a company needs before AI can be used safely at scale.
In the second, we looked at a different problem. Much of what an organisation knows is never properly captured. The reasoning behind decisions disappears from meetings, conversations and everyday work.
The argument was that we should not ask employees to stop working so they can document everything for AI. We should change the working environment so that useful organisational knowledge is captured as a by-product of normal work.
Now suppose you have done that.
You have business data, meeting transcripts, discussions, decisions, the reasoning behind them and, where possible, the eventual outcomes.
You have captured how your organisation thinks.
The obvious next question is:
How do you train AI with all of this?
That question quickly leads to technical terms such as embeddings, vector databases, RAG, knowledge graphs, GraphRAG, CAG and fine-tuning.
If you are a CEO or senior executive, you do not need to know how to build these technologies.
But if you are hiring someone to build an AI system around your company’s knowledge, you should understand what the major components do, how they fit together and why you might need them.
First, what do we mean by training our enterprise AI?
When an executive says, “We need to train AI on our company,” they may simply mean:
I want AI to understand our company well enough to work with our information and the way we make decisions.
Technically, accomplishing that does not necessarily mean training the AI model itself.
Most companies can start with an existing AI model and build a company-specific knowledge system around it.
Suppose the organisation has captured 10,000 previous business decisions.
For each decision, it may have some combination of the business data available at the time, alternatives considered, the decision itself, the reasoning behind it and what eventually happened.
When AI encounters a new problem, the company wants it to be able to find the previous knowledge relevant to that situation and use it.
The basic mechanical process is:
Captured enterprise knowledge → prepare it → organise it so it can be found → retrieve what matters → give it to AI → AI uses it
Let’s follow what happens to the knowledge.
First, prepare the captured knowledge
Imagine one of the records captured in Article 2 is a two-hour management meeting.
The transcript contains 20,000 words covering five subjects.
If AI later needs to understand why Product A was retained, it may not be useful to treat the entire meeting as one indivisible piece of information.
One common technique is to divide the material into smaller useful pieces.
This is called chunking.
One chunk might contain the discussion about Product A.
We can then attach information describing it:
Product: Product A
Meeting: Management Committee
Date: 12 March 2026
Subject: Product retention
Decision: Retain for six months
This descriptive information is metadata.
The distinction is straightforward:
Chunking divides information into useful pieces.
Metadata describes those pieces.
Neither, however, tells the system which piece will be useful when somebody asks a new question.
We now need a way to find it.
Embeddings help us find information by meaning
Suppose someone asks:
Should we discontinue Product A?
Somewhere in the company’s accumulated knowledge, an executive previously said:
The economics no longer justify keeping Product A in the portfolio.
A salesperson wrote:
Demand has fallen to a level where I don’t think we should carry it next year.
And an earlier management discussion concluded:
Unless volumes recover, the product no longer has a viable future.
None uses the word discontinue.
A keyword search looking specifically for that word could therefore miss them, even though they are relevant to the question.
This is one reason embeddings are useful.
An embedding represents the meaning of a piece of information numerically.
You do not need to understand the mathematics to understand what this enables.
It allows a computer to compare pieces of information according to their semantic similarity rather than only whether they contain the same words.
So:
Keyword search finds matching words.
Semantic search can find similar meaning.
Embeddings are what make that kind of vector-based semantic comparison possible.
This does not mean semantic search replaces keyword search. Enterprise retrieval systems frequently combine vector, keyword and other search techniques because they are useful for different kinds of questions.
Where does the vector database fit?
Once we create embeddings, those numerical representations need to be indexed somewhere so they can be searched.
This is where you encounter vector search and vector databases.
The terms are related, but they do not mean the same thing.
Embedding is the numerical representation of meaning.
Vector search compares those representations to find similar information.
A vector database, or another search system with vector capabilities, stores and indexes those vectors so they can be searched efficiently.
The vector layer can therefore become part of the enterprise’s organisational-memory system.
The original source may still be a meeting transcript in Microsoft 365, a policy document, a customer record or a decision stored elsewhere. The vector index helps the AI system locate relevant pieces of that knowledge.
Some implementations also store the corresponding text and metadata alongside the vectors. The important mental model is that the vector layer creates a searchable semantic index into the enterprise’s knowledge.
But similarity of meaning is only one way information can be connected.
Some knowledge is related, not merely similar
Return to Product A.
Suppose the company knows:
Product A is sold primarily to Customer B.
Customer B’s account is managed by Division C.
Management Decision D retained Product A for six months.
Decision D depended partly on Customer B being expected to renew its contract.
Customer B subsequently decided not to renew.
The importance of these facts does not come from the sentences having similar meanings.
It comes from their relationships.
This is where a knowledge graph can become useful.
A knowledge graph represents important things and the relationships between them.
For example:
Product A → purchased by → Customer B
Product A → subject of → Decision D
Decision D → depended on → Contract Renewal
Contract Renewal → associated with → Customer B
This should sound familiar from Article 2.
There, I described an organisational decision thread: keeping the company’s thinking about an important subject connected across meetings, conversations, documents and time.
A knowledge graph is one technical way some of those connections can be represented.
So there is another useful distinction:
Vector search helps find information with similar meaning.
A knowledge graph represents information connected through relationships.
They are not necessarily alternatives.
A company may use both.
Now RAG becomes easier to understand
We have captured the knowledge.
We have prepared it.
We have created ways of finding information through words, meaning and, where necessary, relationships.
Now someone asks:
Should we discontinue Product A?
The AI model does not need the company’s entire organisational memory dumped into the conversation.
It needs the relevant parts.
This is where RAG, or Retrieval-Augmented Generation, comes in.
In simplified form:
Employee asks a question
↓
The system searches approved enterprise knowledge
↓
Relevant information is retrieved
↓
That information is placed into the AI’s context
↓
AI uses it to produce its response
Context is simply the information available to the model while it is working on that particular request.
So RAG is not another database, an embedding, a vector search, or another AI model.
RAG is the process of retrieving relevant external knowledge and providing it to the model as context before it generates its response.
The retrieval itself might use keywords, metadata, vector search, a knowledge graph, or combinations of them.
This is how the components begin to add up.
Where does GraphRAG fit?
Sometimes finding individual pieces of information by keywords or semantic similarity is not enough.
The answer may depend on relationships between customers, products, people, decisions and events.
GraphRAG brings those graph relationships into the retrieval process.
Using our example, the system might identify an earlier Product A decision not merely because its wording resembles the current question, but because that decision is connected to Customer B and to the contract renewal that influenced the original decision.
The distinction is:
RAG retrieves relevant information to give to AI.
GraphRAG uses graph relationships as part of finding and assembling that relevant information.
GraphRAG is therefore not automatically a better RAG.
If the questions the company needs AI to answer depend heavily on relationships spread across organisational knowledge, graph-based retrieval may add value.
If they do not, it may introduce complexity the company does not need.
And where does CAG fit?
You may also encounter CAG, usually meaning Cache-Augmented Generation.
It addresses another variation of the same problem.
RAG finds relevant knowledge when it is needed.
But imagine an AI application repeatedly needs the same relatively small and stable body of information. For example, the HR travel policy, the CS standard response manual, or the HVAC maintenance manual.
Instead of repeatedly retrieving it, there are architectures in which that knowledge can be kept readily available in the model’s context or cache for reuse. Conceptually, it is like keeping a document on the desk rather than filing it away in the filing cabinet.
That is the basic idea behind CAG.
For our mental model:
RAG retrieves the relevant knowledge when it is needed.
CAG keeps a suitable body of knowledge readily available for repeated use.
CAG is a newer and less established term than RAG. An executive does not need to decide which acronym to buy.
If an integrator recommends it, the useful question is:
Which knowledge are you proposing to keep readily available, and why is that better than retrieving it when required?
Put the enterprise-knowledge path together
We can now return to the knowledge captured in Article 2.
One possible path through the machinery looks like this:
Captured enterprise knowledge → chunking and metadata → embeddings → vector search/index → knowledge graph where needed → RAG/GraphRAG/CAG → context → AI uses the relevant knowledge
Not every enterprise application will need every component.
That is important.
A knowledge graph is not something every company must build. GraphRAG is not a compulsory upgrade to RAG. A dedicated vector database may not be necessary if existing infrastructure already provides the required capabilities.
The architecture should follow the problem.
But everything we have discussed so far has one thing in common.
We have been making enterprise knowledge available to an existing AI model without changing the model itself.
That brings us to something different.
What is fine-tuning?
Fine-tuning is frequently mentioned alongside RAG, which makes it easy to assume they are alternative ways of doing the same thing.
They are not.
With the knowledge system we have just described, the enterprise’s knowledge remains outside the model.
When AI needs something, the system finds the relevant information and provides it as context.
Fine-tuning changes the model itself through additional training.
Suppose the company has developed a particular way of evaluating whether a product should be retained.
It may consistently consider customer dependency, strategic importance, contribution margin, contractual consequences and several defined risk factors.
Over time, the enterprise may have accumulated many good examples of its experts performing this analysis.
The company could select suitable examples and turn them into training examples showing, conceptually:
Here was the input → here is the kind of output we wanted.
During fine-tuning, those examples are used in an additional training process that adjusts the model’s internal parameters. The objective is to make the model more likely to reproduce the patterns demonstrated by those examples when it encounters similar tasks later.
That is very different from asking the model to retrieve a Product A document.
Is the data used for fine-tuning different?
This is where the relationship with Article 2 becomes particularly important.
The starting source can be the same captured enterprise knowledge.
The Product A meeting, decision, reasoning and outcome might become part of the organisational memory available through retrieval.
But perhaps it is also an exceptionally good example of how the company wants a product-retention analysis performed.
The company might therefore select it, together with many other good examples, and prepare those examples as a fine-tuning dataset.
The source knowledge can be the same.
What changes is what we do with it.
For the enterprise-knowledge system, we prepare information so AI can find and use what the company knows.
For fine-tuning, we select and prepare examples so the model can learn a pattern of how we want a task performed.
That gives us two paths beginning from the same place:
Captured enterprise knowledge
From there:
Path 1 — Make enterprise knowledge available to AI
Prepare → organise and index → retrieve → context → AI uses it
And:
Path 2 — Fine-tune the model
Select suitable examples → prepare training examples → fine-tune → test on unseen examples → evaluate
The same reservoir of organisational knowledge can therefore potentially support both.
But it is prepared differently because it is being used for different purposes.
How do you actually fine-tune the model?
Conceptually, you begin by selecting good examples of the task performed in the way you want it performed.
Those examples have to be prepared into the training format required by the model and fine-tuning system. At its simplest, the model is being shown repeated examples of the relationship between an input and the desired output.
The additional training process adjusts the model so that the demonstrated pattern becomes more likely to appear when it encounters similar inputs in the future.
But training is not the end of the process.
The fine-tuned model then needs to be tested on examples it did not see during fine-tuning.
Did it actually improve?
Does it generalise to new cases?
Does it perform the task reliably enough?
Did the fine-tuning cause undesirable changes elsewhere?
If it does not perform better, the training examples, their quality, the training approach or even the decision to fine-tune may need to be reconsidered.
Fine-tuning therefore does not remove the need for evaluation.
Neither does RAG.
A retrieval system can retrieve the wrong information. A model can misunderstand good retrieved information. A fine-tuned model can learn an undesirable pattern.
Both systems need to be tested against the outcomes the business actually cares about.
The two paths can work together
Now the distinction becomes useful rather than merely technical.
Suppose the company fine-tunes a model to become better at performing its particular product-retention analysis.
The model still needs to know today’s sales, the latest Customer B contract status, what management decided six months ago and what has changed since then.
That current company knowledge does not have to be baked into the model through fine-tuning.
It can be retrieved when needed.
So the two approaches can work together:
Fine-tuning can help teach the model a specialised pattern for performing the task.
Retrieval can provide the current enterprise knowledge required to perform that task today.
This does not mean every enterprise should fine-tune its model.
It is not the final stage of becoming AI-first.
A company may build an excellent enterprise AI application using retrieval and never need fine-tuning.
The question is always what business problem the additional training is intended to solve.
Who actually builds this?
Throughout this article I have referred to an AI integrator.
That deserves an explanation.
I use the term to mean the person or team responsible for translating the company’s business requirement into a working enterprise AI system.
They are not simply someone who knows how to use ChatGPT or write good prompts.
Depending on the project, they may need expertise in AI models, enterprise data, APIs and system integration, databases and search, RAG, security and permissions, evaluation, monitoring and deployment.
But technical knowledge alone is not enough for the kind of project we have been discussing.
The integrator needs to understand the business problem sufficiently well to translate it into a technical architecture.
That does not mean the integrator needs to arrive knowing your business better than you do.
The company’s domain experts still have to explain how decisions are made, what information matters, which exceptions matter, what a good result looks like and where humans must remain responsible.
The relationship should therefore look something like this:
Business leaders and domain experts define the problem, the knowledge, the boundaries and what good looks like.
The AI integrator translates those requirements into the technical system that allows AI to work within them.
For a narrow technical integration, the integrator may primarily be an engineer or architect.
For a broader AI transformation involving workflows, governance, organisational change and decision-making, the project may require a team combining technical integration with business analysis and change-management capabilities.
The title matters less than whether the required capabilities are present.
Before you talk to your AI integrator
You do not need to walk into that meeting knowing how to build a vector database or fine-tune a model.
But after understanding the machinery, you should be able to ask better questions.
Where will our enterprise knowledge come from?
How will you prepare it so AI can use it?
How will the system find the right information when an employee asks a question?
Are you searching by keywords, meaning, relationships, or some combination?
Why are you proposing a vector database?
Do our business relationships justify building a knowledge graph?
Why do we need GraphRAG rather than a simpler retrieval system?
How will RAG decide what information enters the model’s context?
How will our existing data permissions determine what the system is allowed to retrieve?
Can we see which enterprise information the AI used to produce an important answer or recommendation?
How will you test whether retrieval is finding the right information?
Are you proposing fine-tuning?
If so, what are you trying to teach the model?
Which examples will you use?
Why is fine-tuning preferable to providing the model with instructions, examples and retrieved company knowledge at runtime?
And how will we determine whether the fine-tuned model actually performs better on cases it has never seen?
These are not questions about how to write code.
They are management questions about what happens to the enterprise’s accumulated knowledge and how AI will be allowed to use it.
The first article in this series was about controlling what AI is allowed to know and do.
The second was about capturing the organisational intelligence companies currently lose.
This third step is about what happens captured enterprise knowledge can be organised so AI can retrieve and use it.
Selected examples from that same knowledge can, where there is a good reason, be used to fine-tune the model itself.
Those are different mechanisms, but they can begin with the same organisational knowledge and ultimately work together.
Once you can picture that machinery, terms such as embeddings, vector databases, RAG, GraphRAG and fine-tuning stop being a list of AI buzzwords and become components you can place in your mental map and ask what your enterprise actually needs.
Continue reading