Most data quality problems in an AI project look like model problems at first. The assistant gave a wrong answer, so the team adjusts the prompt, adds examples, changes the retrieval settings or tries a different model. Sometimes that helps. Often the same class of error comes back a week later in a different form.
The reason is that many of these errors are not about language at all. They are about meaning. The assistant answered correctly from the data it was given, and the data contained several correct answers to slightly different questions. No prompt can choose between them, because choosing is a business decision that nobody has made.
That is what weak data ownership looks like in practice. Not a missing name in a catalogue, but an unmade decision that sits between teams until an automated system forces it into the open. CloudNala's view is that AI projects are the fastest data ownership audit an organisation will ever run, and it is far cheaper to run that audit deliberately than to discover it through customer complaints.
Gariep Grain Co-operative is fictional, and its systems and figures are illustrative. In Part 1, Gariep's member assistant told two farmers with identical deliveries two different tonnages. This part follows how that happened and what it took to fix.
One word, four honest definitions
The member asked a reasonable question: "How much have I delivered this season?" Inside Gariep, four teams answered that question every day, each in a way that made sense for their work.
The silo managers counted gross mass as it crossed the weighbridge, because that is what they physically received and what fills their bins. The payments team used net mass after moisture deduction, because the advance payment is calculated on dry grain. Pool accounting used graded mass once the laboratory had signed off, because the final payment depends on grade. And the BI dashboard reported season-to-date figures by ticket date, while pool accounting grouped by grading date, so a load delivered on the last day of a reporting week could appear in different weeks in different reports.
None of these was wrong. Each was the right definition for the team using it. The problem was that the member assistant was a new consumer with a new purpose, member communication, and nobody had decided which definition that purpose required. The assistant used whichever view retrieval or its query tool reached first.
This is the most common shape of the ownership problem. It is not that data has no owner. It is that several teams each own a version, and the cross-team question, "what do we tell a member?", belongs to nobody.
What ownership involves
Data ownership is often reduced to a column in a catalogue: owner, Jane Doe. That records a name. It does not record what the person is accountable for, and in most organisations the named person does not know they are on the list.
Useful ownership splits into several jobs, usually held by different people:
The data owner decides what the data means and what quality is good enough, and accepts the business risk when it is wrong. This must be someone with authority over the process that creates the data. At Gariep, that is the Head of Grain Operations, because grain operations creates every delivery ticket.
The data steward keeps the definitions, the contract and the issue log current. Stewards answer the day-to-day questions so the owner only sees decisions.
The producing team builds and runs the pipelines and fixes failed loads. They are accountable for delivering data that meets the contract, not for deciding what the contract says.
The platform team provides storage, compute, testing tools and lineage capture. They are accountable for the platform working, not for the meaning of any column on it.
Consumers use the published interface and report issues against the contract rather than working around them.
The failure mode Gariep had, and most organisations share, is that the platform team was treated as the owner by default. When the assistant team asked what "delivered" meant, they asked the people who ran the warehouse, because those were the people they could find. The warehouse team gave a sensible technical answer about which columns existed. That was not an answer to the business question.
How the decision got made
The fix at Gariep took one meeting and four weeks.
The meeting brought together the Head of Grain Operations, the payments manager, the pool accountant and the assistant's product owner. The question on the table was narrow: what should a member be told when they ask how much they have delivered? The answer they reached was graded net mass, with a clear status for loads not yet graded: "38.2 tonnes graded, plus 4 loads awaiting grading." The silo managers and payments team kept their own definitions for their own work, because those definitions were correct for their purposes.
The four weeks went on making that decision durable:
- The definition was written into the deliveries data contract, with the reasoning, so the next new consumer would find it.
- A member-facing view was published that exposed only graded net mass and the grading status.
- The assistant was restricted to that view, and its instructions told it to always report the status.
- The steward added a test that compared the member-facing total to pool accounting's figure every night and flagged any difference.
The model, the prompt structure and the retrieval settings were barely touched. The problem was never there.
Signs your organisation has the same gap
Gariep's case is specific, but the signs are general. If any of these are true for a dataset an AI system will use, ownership is weak:
- Two reports show different numbers for what sounds like the same measure, and the explanation requires an expert.
- When a definition is questioned, the first person asked is someone in IT.
- The catalogue lists an owner who has never been asked a question about the data.
- Definitions live in a spreadsheet or a wiki page that nobody is responsible for updating.
- A source system changed its export format and consumers found out by breaking.
- Nobody can say who would approve a change to how a field is calculated.
These are not signs of a bad data team. They are signs that ownership was never assigned as a job with authority and time attached to it.
The trade-off: owners need time and authority
The reason ownership stays weak is that it costs something. An owner has to attend meetings, make decisions that some teams will not like, and answer for errors. Business leaders who are measured on operations rarely see owning data as part of their role, and nobody adds it to their objectives.
Two things make it workable. First, scope: an owner is needed for the handful of datasets that several teams and an AI system depend on, not for every table. Second, support: a steward does most of the routine work, so the owner's time goes on decisions. At Gariep the Head of Grain Operations spent perhaps two hours a month on the deliveries product once it was set up. The steward spent a day a week.
There is also a governance link worth making explicit. Section 16 of POPIA requires a responsible party to take reasonably practicable steps to ensure that personal information is complete, accurate, not misleading and updated where necessary, having regard to the purpose for which it is processed. A member being told the wrong tonnage of their own grain is a data quality failure about their personal information. That is a reason to treat ownership as a control, not a nice-to-have. This is general information, not legal advice; your privacy officer should make that determination for your context. For a broader view of POPIA and AI, see What POPIA means for your data and AI strategy.
Where to start
Do not launch an organisation-wide ownership programme. Take the AI use case you are working on, list the three or four business terms its answers depend on, and for each one ask: who decides what this means for this purpose? If the answer is unclear, that is the first decision to get made, before any further prompt or model work.
For the information-architecture side of the same problem, including why a semantic layer is your hallucination control, the No AI Without Information Architecture series goes further.
Next: Part 3, RAG, fine-tuning and knowledge graphs solve different problems. All parts are on the series page.
How CloudNala can help
We run short sessions that take a live AI use case, trace every answer it gives back to the business terms and datasets behind it, and identify which definitions need an owner's decision. The output is a short list of decisions, the people who should make them, and the contract and test changes that make each decision stick.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Data Readiness Review or write to us at consult@cloudnala.co.za