Who maintains the knowledge your AI uses?

AI can provide two different answers to the same question even when both are grounded in genuine internal documents. The reason may precede any technical processing: two departments understand the same term differently. Improving the wording of the instruction alone leaves that underlying disagreement unresolved.

This guide addresses a specific leadership responsibility: deciding who owns the meaning and validity of the knowledge an AI application is meant to use. It is intended for hospitals, pharmaceutical companies, medical technology businesses and other knowledge-intensive organisations. The examples are fictional; the proposed approach is an original organisational inference.

An example: what does available capacity mean?

Imagine a hospital whose leaders ask about available capacity for the following week. One report counts physically available places. A second counts places for which staffing is planned. A third also considers capacity already committed. All three figures could have been collected correctly while supporting different decisions.

An answer without a visible definition could imply a degree of certainty that the documents do not support. Before automating it, the hospital should agree which metric answers which question. Several useful metrics may coexist. They need distinguishable names and an explained purpose.

The WHO framework for routine health-facility data addresses completeness, timeliness and consistency, alongside organisational responsibility for data quality. It does not examine an AI application, but provides a useful reference for the quality of the information on which one depends. [1]

Define a small unit of knowledge

Begin with a frequent question that genuinely supports a decision. In the example, it is: what capacity can we commit under our current plan? The knowledge required contains more than a number. It includes the definition, time reference, responsible function and conditions under which the answer may be used.

For this unit, I suggest a short agreement containing six fields. First, the decision to support. Second, the precise meaning of the term. Third, the authoritative information source. Fourth, the accountable subject owner and deputy. Fifth, the current validity date and trigger for another review. Sixth, the procedure for contradictions or missing information.

For the capacity example, the agreement could state that the figure describes capacity currently planned with staff and not yet committed. A subsequent staffing-plan change would trigger a new calculation. A different question, such as the potential for physical expansion, would receive a different metric with its own name.

These fields are a working proposal. Their number is not a scientifically established limit. An organisation should shorten or extend the agreement if the particular decision requires it.

Separate responsibilities so decisions remain possible

Subject ownership determines meaning. Technical ownership delivers what has been agreed. Approval establishes whether and under what conditions the information can be used in the intended workflow. In a small organisation, some of these roles may belong to the same people; the responsibilities should still be distinguishable.

A technical team might demonstrate that a number was correctly transferred from a table. Whether that table counts staffed capacity or physical places needs a subject-matter decision. Combining both questions in one undifferentiated error report makes the necessary decision harder to assign.

Name a deputy as well. A knowledge base whose meaning only one person can explain becomes difficult to maintain during absence, staff changes or excessive workload. The deputy should be able to use an example to explain how the definition applies and where its limits lie.

Keep the past interpretable when definitions change

Suppose the hospital decides to include another condition in its capacity figure from October onwards. A decline compared with September might then arise partly from the revised definition. Without a version reference, it could appear to be an actual loss of capacity.

The W3C recommendation on publishing data describes provenance, versions and changes. I apply that principle here to internal knowledge maintenance: a new definition should have an effective date and a brief explanation of what changed. Earlier versions remain interpretable for as long as the relevant retention purpose requires. [2]

This creates a clear requirement for the AI answer: the underlying version must be identifiable. If a request spans several periods, the system should make different definitions visible or refer the question for subject-matter clarification. A fluent summary should not conceal the absence of a shared basis for comparison.

Quality depends on the intended use

A report maintained monthly may be sufficient for long-term planning and unsuitable for a decision that afternoon. The knowledge agreement should therefore state which time horizon it supports. The required precision also follows from the decision.

The W3C's 2016 working-group note on the Data Quality Vocabulary accommodates different quality assessments for different uses. It does not supply a universal score above which a dataset becomes suitable for every purpose. [3] My operational inference is that the person responsible for the intended use should help establish a justified requirement for freshness and accuracy.

In the example, the hospital might allow an approximate capacity overview for a strategic discussion. A specific commitment would require the designated current confirmation. This distinction belongs in both the answer and the workflow so that users understand which next action is possible.

Start with a small, visible maintenance commitment

Choose three recurring questions. Complete the agreement with the accountable subject owner, then examine one ordinary request, one contradictory request and one request containing incomplete information. Approved artificial data are sufficient. Discuss which ambiguity became visible only through the exercise.

After an agreed period of use, review the questions received. Did any definitions need to change? Could the deputy act? Were answers based on an outdated version? Include the effort required for this maintenance when deciding whether to expand the application.

If the three initial questions turn out to require very different update cycles, preserve those differences. A single review schedule may be convenient administratively while obscuring the needs of each decision. The agreement should make those needs manageable for the people who actually maintain the information.

For me, this is a concrete form of leadership responsibility for AI: the organisation decides what its terms mean, who owns changes and when an answer can be used. The clearer those agreements become, the more precisely technical assistance can be directed towards them.