When evidence expires: Building AI systems that can be audited

On July 27, 2026, the European Union's AI Omnibus entered into force, moving the application of high-risk AI rules in certain sensitive areas to December 2, 2027 and rules for AI embedded in regulated products to August 2, 2028. Six days later, the European Commission's AI Office and national authorities began enforcing other provisions of the AI Act, including transparency requirements for certain AI systems and AI-generated content.

The calendar changed, but the underlying engineering problem did not. A contract clause superseded three years ago remains superseded, and a retrieval system with no sense of time can still surface it as authoritative. For organizations using artificial intelligence in consequential workflows, the harder question is whether a system can identify its evidence, establish that the evidence remains valid and respond appropriately when the record is incomplete or contradictory.

That question was posed to Himanshu Goel, a senior AI engineer and researcher with more than six years of experience. Across regulated financial, healthcare and audit environments, his work has spanned predictive modeling, document intelligence, retrieval systems and AI governance. That progression moved him from optimizing individual models toward designing the architecture around them.

Goel holds a master's degree in computer engineering from New York University and co-authored a paper on AI-driven physical identity and cyber-physical zero trust published in the proceedings of IEEE ICSSAS 2026. His ongoing research examines outdated evidence, information scattered across long documents, contradictions that fluent summaries can conceal and evaluation methods that can make weak systems appear reliable. He was a keynote speaker at GBRC 2026 and served as an AIVR 2026 session chair and presentation evaluator. He has also judged the 2026 SiliconANGLE TechForward Awards, Technovation and the CodeSpring Hackathon.

Earlier in my career, a project could often be framed around a specific model and a narrow outcome. Over time, I saw that many important failures happened outside the model itself. A document might be processed incorrectly, retrieval might miss the controlling passage or an outdated source might be presented without its history. Even a technically strong model could fail if the surrounding system was weak.

That pushed me toward owning more of the complete workflow: How information enters the system, how it is classified or routed, what gets retrieved, how evidence is evaluated and what the user sees. The model is still important, but it is one component in a larger engineering system.

Most retrieval systems divide a document into smaller passages, often called chunks, and find the passages most similar to a question. That approach is useful, but similarity alone does not establish how different passages relate to one another.

In the contract example, the answer may depend on three passages that are individually incomplete. The effective date establishes the starting point, the renewal clause changes the duration and the amendment may override both. Retrieving only the closest passage can produce a plausible answer that is no longer current. In a compliance workflow, that could mean relying on superseded language while the system presents it as authoritative.

The engineering challenge is to preserve document structure, dates, versions and relationships among evidence before generating a response.

Additional context can increase coverage, but it can also introduce repetition, conflicting versions and irrelevant text. A long prompt does not guarantee that the model will identify which passage controls the answer.

I think of context selection as an evidence problem. The system should retrieve broadly enough to avoid missing relevant material, then rank the evidence carefully. Reranking means taking the initial search results and ordering them again with a more precise relevance model. The system also needs a threshold for declining to answer when support is weak. In a high-stakes workflow, visible uncertainty is more useful than confidence built on incomplete material.

It showed me that cost is often determined before the main model is called. I designed a lightweight computer-vision layer that examined visual characteristics of document images and routed simpler cases through a less expensive path. Uncertain inputs retained access to the more resource-intensive process.

The system used different levels of computation according to the document instead of forcing every input through the same route. That reduced unnecessary processing while preserving a fallback for difficult cases.

The same principle applies to generative AI. An embedding is a numerical representation used to compare the meaning of text. Before creating embeddings for every page, it is worth asking whether every page adds new information and whether a smaller component can make the first decision. Architecture and resource allocation can matter as much as the model selected at the end of the pipeline.

Semantic fingerprinting creates a compact representation of a document's meaning so duplicate or near-duplicate material can be recognized. The objective is to avoid treating every repeated clause as entirely new while retaining metadata that identifies the source.

Two-stage retrieval narrows the search in steps. A system might first identify the relevant records or documents, then search the most relevant passages within that smaller set. This can reduce unnecessary computation and improve traceability because the path from the question to the evidence remains visible.

These approaches add orchestration and are most useful when collections are large, repetitive and subject to audit. The design should follow the information rather than add complexity for its own sake.

The user should be able to see the provenance, meaning the source and path behind the answer. That includes the relevant document, the passage used and any date or version information that affects interpretation.

The system should separately check for stale evidence and contradictions. It should record how retrieval was performed, apply appropriate access controls and make uncertainty visible. Evaluation must reflect the real task as well. A system can retrieve a relevant-looking passage and still miss the controlling amendment or a conflicting source. Surface similarity will not reveal that failure.

Reliability comes from the workflow around the model: Ingestion, retrieval, evidence checks, generation, logging and human review. Each layer has a specific responsibility.

The first step is to ask exactly what was tested. Was it a controlled experiment, a limited proof of concept or an operating system used in a real workflow? Each can provide useful evidence, but they support different conclusions.

Industry work exposes practical problems, while research makes it possible to isolate a failure and test it under controlled conditions. They inform each other, but an experimental architecture should only be described as deployed when there is evidence that it was implemented in that setting. An operational result should also be treated carefully before it is generalized into a scientific claim.

Credibility depends on distinguishing what has been demonstrated, what remains under study and what still needs stronger evidence.

I would look for evidence controls becoming a normal part of system design rather than an optional layer added near deployment. For consequential answers, systems should identify their sources, check dates and versions, surface contradictions and abstain when support is insufficient.

Success should also be measured beyond model accuracy. Teams should examine retrieval quality, processing time, infrastructure cost, manual effort and how often users need to correct the system. Those measures would indicate that enterprise AI is becoming durable infrastructure: Software that can produce an answer while also explaining why the evidence deserves attention.

This article was written in cooperation with Tom White