Buying another AI tool will not solve a data problem.
A sales team can add an AI assistant to its CRM, a support team can connect a chatbot to its knowledge base, and an operations team can automate reporting. But if the underlying information is incomplete, inconsistent, inaccessible, or trapped in people’s heads, those systems will produce unreliable work faster.
That changes the leadership question. The issue is not simply which model or application to buy. It is whether the business has a usable data layer: trusted information, clear ownership, sensible governance, and workflows that make knowledge available where decisions happen.
The source video frames this as a shift in the role of data. It is no longer only a historical record used for periodic reporting. It can become a living operational asset that helps a business interpret events and respond while they are happening. For leaders trying to move from AI experiments to dependable production workflows, that foundation matters more than another feature comparison.
The commodity trap: models are not the whole advantage
AI models are becoming easier for businesses to access, and the performance gap between proprietary and open models is not necessarily a durable source of differentiation. The source points to a 2023 Google memo as an example of this broader shift, though that specific reference should be independently verified before being used as evidence in a formal business case.
The practical implication is straightforward: a model that many businesses can access is unlikely to be your lasting moat. Your advantage is more likely to come from what the model can understand about your company that competitors cannot easily reproduce.
Consider two commercial teams using similar AI tools:
- Business A asks AI to draft follow-up emails using generic CRM fields such as company name, opportunity stage, and last contact date.
- Business B gives its system access to consistently captured discovery notes, objections, implementation constraints, buying triggers, successful proposal language, and post-sale lessons.
Both may use the same underlying model. Business B has the more valuable system because its data reflects how the organisation actually wins, loses, serves, and retains customers.
This is why leaders should treat internal knowledge as an asset rather than a by-product of daily work. The question is not whether the business has data. It is whether the business has distinctive, reliable data that can be used inside a workflow.
From reports to a living operational asset
Many organisations still use data mainly to explain what happened last week or last month. Teams export spreadsheets, update dashboards, prepare management packs, and discuss exceptions in meetings. That process can be useful, but it leaves a gap between an event occurring and the business acting on it.
A more operational data layer connects information to decisions in closer to real time.
For example, a service business might currently:
- Record completed jobs in a field system.
- Export performance data at the end of the month.
- Notice recurring delays during a management meeting.
- Ask an operations manager to investigate manually.
- Make a process change weeks after the pattern first appeared.
A more responsive workflow could flag repeated delays as they emerge, combine job records with technician notes and customer messages, and route a review to the person responsible for scheduling or quality. The goal is not real-time data for its own sake. The goal is to shorten the distance between a meaningful signal and a useful decision.
That distinction is important for smaller organisations. A full streaming architecture may be unnecessary if the workflow bottleneck is a weekly handover or a badly maintained spreadsheet. The right starting point is the decision that needs to improve, not the most sophisticated data infrastructure available.
The 90% problem: unstructured knowledge is often the missing layer
The source highlights a commonly cited estimate that roughly 90% of organisational data is unstructured, including emails, PDFs, recordings, documents, and meeting notes. The exact figure and citation should be checked before being presented as a verified benchmark, but the operational observation is sound: a large amount of business knowledge does not live in neat database fields.
This matters because unstructured information often contains the context that structured systems leave out.
A CRM may record that an opportunity was lost. The proposal file may show that the buyer considered the implementation timeline too risky. An email thread may reveal that a competitor offered a more flexible contract. A call recording may show that the prospect’s stated objection was not the real concern. A project debrief may contain the specific workaround that prevented a similar customer from churning.
That is proprietary qualitative knowledge: the unwritten judgement developed by people working with customers, suppliers, products, and operational exceptions.
To make it useful, leaders do not need to convert every document into a giant database. They need a repeatable process for capturing the parts of that knowledge that affect future decisions.
A practical workflow for a sales team could look like this:
- Capture: Require a short post-call note using consistent prompts: customer problem, business impact, objection, decision criteria, next step, and confidence level.
- Clarify: Have the account owner distinguish direct customer statements from their own interpretation.
- Classify: Apply simple labels such as industry, use case, objection type, competitor, buying stage, and outcome.
- Govern: Assign an owner to review sensitive, outdated, or contradictory information.
- Use: Make the knowledge available in the next workflow, such as opportunity reviews, proposal preparation, onboarding, or customer health monitoring.
- Learn: Compare the captured assumptions with the eventual outcome and update the process.
This turns field wisdom into an organisational capability instead of leaving it with the employee who happened to attend the meeting.
Why AI amplifies flaws instead of fixing them
AI can make messy information easier to search, summarise, and distribute. It does not automatically make that information true, current, or appropriate to use.
If a business has duplicate customer records, an AI assistant may combine them incorrectly. If different teams use different definitions of “qualified lead,” an automated report may create a confident but meaningless pipeline view. If an old pricing document remains in the knowledge base, a drafting system may use it in a proposal. If staff record important decisions only in private inboxes, the organisation may have no reliable source for an automated workflow to consult.
The failure is not necessarily the model. It is often the absence of basic operational decisions:
- What is the authoritative source for each type of information?
- Who owns its quality?
- How quickly does it become out of date?
- Which fields or documents are required for a decision?
- What should happen when two sources disagree?
- Which data may the system access, and which must remain restricted?
Leaders need to own these questions because they cross departmental boundaries. A software team can connect systems, but it cannot decide whether sales, finance, or delivery has the final say on a disputed customer status. That is a business governance decision.
A six-step data-layer audit
Before scaling an AI workflow, run a focused audit around one business process rather than attempting to clean the entire organisation.
1. Select a costly decision. Choose a process where delays, errors, or inconsistent judgement have a visible commercial impact: lead qualification, renewal risk, quoting, support escalation, or project handover.
2. Map the information required. List the records, documents, conversations, approvals, and human judgements currently used to make the decision.
3. Find the gaps and silos. Identify information held in inboxes, personal folders, spreadsheets, meeting recordings, or disconnected applications.
4. Define minimum standards. Specify required fields, naming conventions, retention rules, review frequency, and the meaning of important terms.
5. Assign ownership. Name a person or team responsible for quality and escalation. “Everyone owns the data” usually means no one does.
6. Test the workflow manually first. Before automating, ask whether a trained employee could follow the process using the available information. If the answer is no, automation is premature.
Once the process is reliable, AI may help with retrieval, classification, summarisation, drafting, or routing. It should be added to a functioning workflow, not used to conceal one that is failing.
Callout: Start with knowledge that changes decisions
Do not begin by collecting everything. Begin with the undocumented knowledge that repeatedly affects revenue, delivery quality, customer retention, or risk. Capture one category of field wisdom, make it usable, and learn from the workflow before expanding it.
Limitations and failure modes
Building a dependable data layer is not a quick clean-up exercise. Legacy records may be inconsistent, and qualitative knowledge is difficult to standardise without losing context. People may also resist documentation if it feels like administrative work with no immediate benefit.
Real-time data integration has its own trade-offs. It can introduce additional cost, technical complexity, monitoring requirements, and privacy risks. A small business may gain more from a well-designed daily review than from a technically impressive streaming system.
There is also a risk of over-structuring knowledge. If every conversation is reduced to rigid fields, important nuance may disappear. The aim is not to eliminate judgement. It is to preserve enough context for people and systems to make better decisions.
Finally, better data does not remove the need for human accountability. AI-generated summaries can still omit critical details, and a clean data set can still support a poor business policy. Governance must include review, correction, access controls, and clear points where a person remains responsible.
Frequently asked questions
Does a small business need a complex data platform before using AI?
No. Start with one workflow and its most important decisions. A shared, well-maintained source with clear ownership can be more valuable than a large platform filled with unreliable information. Add integration and automation when a specific bottleneck justifies the investment.
What counts as proprietary qualitative knowledge?
It is the practical judgement that teams build through experience: why certain customers buy, which objections signal genuine risk, how a service issue is usually resolved, what implementation detail causes delays, or which proposal language creates confusion. It often appears in notes, emails, calls, documents, and conversations rather than standard database fields.
Should leaders prioritise structured or unstructured data first?
Prioritise the data needed for the decision you are trying to improve. Structured records are easier to automate, while unstructured sources often contain valuable context. In many cases, the best approach is to connect the two: use structured fields to filter and route work, then use approved documents or notes to provide supporting detail.
How can a leader tell whether an AI workflow is ready to scale?
Check whether the workflow has a defined outcome, a trusted source of information, an owner for data quality, an escalation path for uncertainty, and a way to measure errors and business impact. If those elements are missing, more automation will usually increase exposure rather than create reliability.
AI adoption is therefore less about finding a perfect tool and more about making the organisation legible to itself. The businesses best placed to benefit will be the ones that identify their valuable knowledge, govern it deliberately, and connect it to the decisions that matter.
The first practical move is modest: choose one workflow, audit the information behind it, and document the field knowledge that currently exists only in people’s heads. That is where a usable data layer begins.