When AI fills in the status column, the agent reading it may see a decision nobody made

When a document library fills up with AI-generated metadata, the “status” column of a procedure can read “in force” without any person having decided so. The tool read the document and derived a plausible value. The agent that queries the library next will read that value as a company decision. The costly error is the plausible value: an absurd one eventually gets spotted and fixed, a plausible one looks like what everyone expected, and nothing prompts anyone to look at it.

This piece is written for the CDO, CTO or head of knowledge management at a large group preparing its document libraries for internal assistants and agents. If your status columns are still typed by hand by document authors, the argument will apply the day autofill is enabled on a site: a user with sufficient permissions on a library can then create such a column, without any programme being launched.

The person this piece makes uncomfortable is the document control manager of a quality department. At a management review, an internal auditor shows her the answer the procurement assistant gave the day before: it cites version 3 of the supplier qualification procedure, marked “in force” in the library. Version 4, approved in the spring, sits in another folder. The auditor asks: “Who put version 3 in force?” She looks for a validation and finds none: the value was filled in when the file was uploaded, by the library’s automated processing, from the text of the procedure, which still says “applicable from the date of issue”. Nobody in the room can say who decided.

The check this piece proposes costs nothing. In a library where a status column is filled by AI, filter the documents marked “in force” and pick three. For each, find out who validated that value. If the answer is “nobody”, you know what your agent is reading, and the column described below is the first job. If every value has a name and a date, your exposure lies elsewhere, and you can move on to the version and effective-date fields.

Two answers come to mind straight away. The first is the in-house practice: let the AI classify, and count on users to correct the errors they see. The second is the tool already in place: the document management system’s approval workflow, which has each document validated before release. The approval workflow validates the document; it does not see the column that a process later adds next to it. Correction through use catches the wrong values that show. Neither tells you who decided that a plausible value is true.

This piece follows on from our 25 September article, about an AI programme rebuilding the description of documents: here there is no programme, just a column an authorised user switches on in a library. It also comes earlier in time than our 2 October article, which started from a wrong answer already given: here, nothing has been answered wrongly yet.

What autofill does, at its best

The tooling deserves to be described as its vendor documents it. Microsoft’s documentation of SharePoint autofill columns describes a prompt saved on a column, run on each file added to the library, with the response saved in the column. It can classify a document, extract a value, summarise or analyse its content. The same page states that this metadata can be indexed, trigger a workflow, or serve as a criterion for applying an information protection label. It warns: “AI-generated content might be incorrect. Be sure to check the column results.” It adds that document changes are captured only if the file is reprocessed, manually, by the user. Copilot in SharePoint can now suggest and create these columns from the library’s content.

This is real progress for libraries nobody was tagging, and the vendor’s warning is honest: it asks people to check. The mechanism described here is generic, it applies to any tool that writes metadata by reading the document, and we do not know whether, or how, each deployment distinguishes a value reviewed by the business from one that was not.

The boundary fits in one sentence: the tool produces a reading of the content, and the column files it in the same place as a decision. The instruction to check is addressed to the user looking at the column. The agent that reads it tomorrow looks at nothing: it receives “in force” and treats it as company information about the document.

This is where the document control manager comes back in. She let nothing slip: the approval workflow worked for version 4, and nobody ever put version 3 back in force. The value was born of a reading, and was then read as a decision.

Why AI-generated metadata needs a provenance

Call it a circular label: a metadata value written by an automated reader and then consumed as a decision by another automated reader. It shows up when you separate, for each value, what was read from what was validated; reviewing the column on its own does not reveal it.

Three properties make it costly. It is plausible: the tool reads what the document says about itself, and an outdated document can go on saying it applies. It spreads: a column can be indexed, trigger a workflow or drive a protection label, so a reading becomes an access rule or a process step. It freezes: if the document changes without being reprocessed, the value stays that of the first reading.

The fields carrying this risk are the ones that express a decision: status, applicable version, scope, effective date, confidentiality. Descriptive fields, such as topic or document type, carry far less: an error there degrades search, it does not get a withdrawn rule applied.

One industry has already written it down

The pharmaceutical industry got to the question first. The draft Annex 22 “Artificial Intelligence” to the EU Good Manufacturing Practice guidelines, under consultation from 7 July to 7 October 2025, excludes generative AI from critical uses and provides that, in non-critical uses, adequately qualified personnel should always be responsible for ensuring outputs are suitable for the intended use. For the models it covers (static and deterministic), where a model gives an input to a decision made by a human operator, it asks for records of that review process to be kept. In May 2026, an inspector from Ireland’s HPRA stated that the text was still in draft, under revision after the consultation.

The text applies to manufacturers of medicinal products and active substances, and it is not binding at this stage: outside that industry, no text currently asks the same of a library column. We borrow its method, not its object: this piece is not about GMP. The method is simple: a model output that serves as the basis for a decision says who reviewed it. A status value serves as the basis for an agent’s decision; it can say the same.

The provenance column

The check in the introduction produces an artefact: a provenance column, placed next to each AI-filled decision column.

What it holds. For each document: where the value in the neighbouring column came from, in one of three states. “AI reading, not validated”. “Validated by” followed by a role and a date. “Entered by” followed by a role, when the value was typed by hand.

Where it lives. In the library itself, in the content type that already carries the status column. It is maintained by whoever administers the library, under the rule set by document management. It does not live in a separate file.

When its first rows get written. When any new AI-filled column is created, before it is switched on. For libraries already equipped, at the next periodic document review, when authors are already reconfirming their documents. Never at the moment an agent has just cited a withdrawn version: that is the opening scene, and it leaves time for nothing.

A filled-in row. Document: supplier qualification procedure, version 3. Status column: in force. Provenance column: AI reading, not validated. Decision at the review: status corrected to “superseded”, provenance changed to “validated by the quality document control manager”, with the review date.

Its reading rule. A “validated” or “entered” value is served to the agent as company information. An “AI reading, not validated” value is served as an indication, or removed from the criteria the agent uses to choose the applicable version, depending on what your tooling allows. Until a decision column has its provenance column, it stays, if your tooling allows, out of the agent’s retrieval criteria; users still see it in the library, and the agent relies on document content as it did before the column was switched on.

How it fails. If the exercise works, it surfaces documents marked “in force” that nobody validated, and someone will have to confirm them one by one. That is its cost: one column per library and a validation pass at the next review. If it fails, it fails the other way: everything gets marked “validated” in one bulk action to clear the queue. The periodic review shows it, because a validation dated the same day across a large number of documents looks like no review at all.

The record it creates. A dated “validated by” value establishes that, on that date, an identified role confirmed a document’s status. If the confirmation was wrong, the record shows it. It is our reading, with no published decision to support it, that a dated and attributed validation remains preferable to a value nobody reviewed: it lets you correct and say since when. Your legal and compliance functions should be consulted before making it a group rule.

The column creates no new role. It attaches to the document review that document management already funds and, if you are deploying agents on your libraries this year, to the project rolling them out.

What a real deployment showed, and what it does not establish

At an industrial group listed on the CAC 40, the assessment carried out with K-AI established that 32% of the document base studied consisted of divergent duplicates: several versions of the same content that no longer say the same thing. They were surfaced in two weeks and resolved in six. These are exactly the documents on which a status column filled by reading is dangerous: two versions of the same procedure can each present themselves as applicable, and an automated reader can mark both “in force”.

The boundary of this evidence has to be stated. It establishes that a document base in production can carry a significant share of competing versions, and that they can be resolved within weeks. It does not concern AI-generated metadata and does not measure how many status values would be wrong in your library. The provenance column is how you investigate that question in your own organisation.

What the DKP adds, and where it stops

A Document Knowledge Platform (DKP) is the document quality and governance layer that runs upstream of AI systems: it governs the document estate (Govern), detects and treats anomalies, duplicates, obsolescence and contradictions (Clean), and only activates the corpus for agents once those two steps hold (Activate). It replaces neither the document management system, nor metadata autofill, nor the data catalogue. It is not sold as an auto-classification tool and does not belong in a tender for that category. This position does not depend on vendor release calendars: the document layer comes before the engine, whatever tool fills the columns.

Its unit of work is the document set against the other documents in the estate. A column filled by reading looks at one file at a time; version 3 of the procedure nowhere says that a version 4 exists. What a DKP adds is that cross-view: it flags documents that exist in several versions, or of which a more recent version sits elsewhere in the estate, and routes them to the expert who can confirm which one applies.

K-AI is accountable for that detection, for its reproducibility and for routing each case to the right expert. Validating a status value stays with the business and with document management. Technically, the analysis covers only the designated document content, within a contractual ingestion scope; usage logs and telemetry stay in your tools. No data is reused to train models.

And if you do nothing

The status quo has a predictable outcome. Columns will fill up library by library, as authorised users switch them on, and agents will read every value with the same confidence. The auditor’s question will come anyway, about a document you did not choose.

Conclusion: audit, clean, monitor

Audit: in an equipped library, take three documents marked “in force” by AI and find out who validated that value. Clean: have the business confirm or correct unvalidated decision values, starting with documents that exist in several versions. Monitor: add a provenance column to every new AI-filled decision column, before it is switched on.

At the next management review, the document control manager will answer the auditor’s question by opening the library: version 3 reads “superseded”, validated at the last review, and the procurement assistant cites version 4.

Frequently Asked Questions

Is AI-generated metadata reliable?

It is a reading of the document’s content, useful for descriptive fields such as topic or type. For fields that express a decision, such as status or applicable version, a plausible value can be wrong, because an outdated document can go on saying it applies.

Isn’t the document management approval workflow enough?

It validates the document before release. It does not validate a column that an automated process later adds next to the document, nor its value.

Which columns should be protected first?

Those that serve as the basis for a decision: status, applicable version, scope, effective date, confidentiality level. An error there gets a withdrawn rule applied or opens access; an error on a topic only degrades search.

What should we do with values AI has already filled in?

Mark them “AI reading, not validated” in a provenance column, then have them confirmed at the next document review, starting with documents that exist in several versions.

Why does this matter for AI agents?

Because an agent uses metadata to choose which document to cite. A user can doubt a value; an agent treats it as company information.

What confidentiality framework applies to a review of the document estate?

The ingestion scope is contractual and limited to the designated document content, excluding usage logs and telemetry. No data is reused to train models. The scope is validated jointly by the business Document Owner and the CISO or DPO, never by IT alone.

Sources

• Microsoft Learn — Overview of autofill columns — prompt saved per column; metadata that can be indexed, trigger workflows or protection labels; “AI-generated content might be incorrect”; manual reprocessing after document changes.
• Microsoft Support — Create autofill columns (Copilot in SharePoint) — Copilot suggesting columns from library content.
• European Commission — consultation on Chapter 4, Annex 11 and new Annex 22 of EudraLex Volume 4 — consultation from 7 July to 7 October 2025.
• European Commission — draft Annex 22 “Artificial Intelligence” (PDF) — section 1 (generative AI excluded from critical uses; human in the loop for non-critical uses), 3.3 and 10.5 (human review and records, for covered models).
• HPRA — Q&A, QP Forum, Trinity College Dublin, 12 May 2026 (PDF) — Annex 22 still in draft, under revision.
• K-AI — clients page — CAC 40 industrial group (anonymised case): 32% divergent duplicates, surfaced in two weeks, resolved in six.

---

Where to Go From Here

K-AI Corpus Diagnostic — 10 business days on your document estate, full report of the 20 most critical anomalies, money-back guarantee if no meaningful anomaly is found. A one-hour conversation can start from the provenance column of one of your libraries: together we look at which documents marked “in force” have another version elsewhere in the estate, which rows would move to “AI reading, not validated”, and which expert each one should go to. Reach the K-AI team: contact@k-ai.ai. The scope of every diagnostic is validated jointly by the business Document Owner and the CISO/DPO, never by IT alone.

K-AI already works with CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies and CEVA Logistics. Partners: AWS, Snowflake, Microsoft, Wavestone, Devoteam.