A supplier questionnaire comes back from a client's legal team with a single line flagged for response: confirm the AI system's compliance with the EU AI Act. Nobody in the business can answer it. The tool in question reads the firm's own policies and answers staff questions about them. It is not making credit decisions or screening job applicants. The legal team has asked anyway, because their own client asked them first.
That route matters, because EU AI Act auditability requirements can land on a compliance function through a counterparty's due diligence rather than through a regulator, and a due-diligence questionnaire does not stop to check which obligations actually apply to you. The awkward part is that the question as posed has no clean answer, because the Act does not impose one uniform standard on every AI system. What it imposes depends on what the system does and on which role your firm plays in relation to it. Getting those two things straight first is what turns an unanswerable question into a short, evidenced paragraph.
This post sits within our wider guide to DORA compliance for regulated industries, and covers what the Act actually asks of an internal knowledge platform, what evidence satisfies it, and what to require of a vendor before signing.
What the Act asks, and of whom
The EU AI Act entered into force in August 2024 and applies in stages. Two structural features do most of the work in any assessment.
Obligations follow risk classification. The Act sorts AI systems into tiers. A small set of practices is prohibited outright. A defined category of high-risk systems, largely those used in areas such as employment, credit, education, essential services, and law enforcement, carries the heavy obligations: risk management, data governance, technical documentation, record-keeping, human oversight, and post-market monitoring. Systems outside those categories carry far lighter duties, mostly around transparency where a user might not realise they are interacting with AI. Most internal document-question tools sit in this lighter group.
Obligations also follow your role. The Act distinguishes the provider who develops and places a system on the market from the deployer who uses it. A firm adopting a third-party AI knowledge platform is usually a deployer, not a provider, and deployer duties are narrower. They are not nothing: where a system is high-risk, a deployer has real obligations around human oversight, using the system per instructions, and retaining logs. But the technical documentation and conformity work sits with the provider, which is why the honest answer to a questionnaire often begins by naming which party owes what.
EU AI Act auditability requirements in plain terms
Strip the terminology away and the Act's evidence expectations for a high-risk system reduce to three questions a firm should be able to answer after the fact.
Can you show what the system did?
The record-keeping and logging obligations exist so that a system's operation over its lifetime can be reconstructed. For a knowledge platform the practical translation is specific: can you produce, for a given answer given on a given date, the query, the response, and the documents it drew on. If the answer involves exporting application logs and correlating them by timestamp, you have a forensic exercise rather than a record.
Can you show how it was built and assessed?
Technical documentation and risk-management evidence sit with the provider for high-risk systems, which means that for a buying firm this is a procurement artefact rather than something to construct. The question at diligence is whether the vendor can hand it over, and whether its declared scope actually covers the system you are deploying. That scope question is the same one a management system certificate turns on, which our guide to what ISO 42001 requires works through in detail.
Can you show a human was meaningfully in the loop?
Human oversight is an obligation about design and use together. For document-answering tools, the substantive version of this question is not whether a person could intervene in principle, but whether a person decided which documents the system was allowed to answer from, and whether that decision is recorded with a name and a date.
Why "not high-risk" does not close the question
It is tempting to classify an internal knowledge tool as outside the high-risk categories, note the lighter transparency duties, and move on. That is usually the correct classification and it is rarely a sufficient answer, for three reasons.
The first is that auditability arrives by other routes regardless. The accountability principle in the GDPR already requires a controller to demonstrate compliance rather than assert it, and if the documents being read contain personal data, that duty applies whatever the AI Act says. Sectoral regulators add their own expectations; financial entities in scope of DORA face a parallel and in places stricter evidence regime, which we cover in our guide to DORA Article 28 and AI knowledge platforms.
The second is that classification is not static. A tool procured to answer questions about internal policy gets pointed at new material as it proves useful. The moment its answers start informing decisions in a high-risk domain, the assessment that put it outside scope needs revisiting, and a platform with no answer record makes that reassessment guesswork.
The third is commercial rather than legal. Your client's questionnaire will keep arriving whether or not the Act obliges you to answer it, and "we determined the system is not high-risk" is a weaker response than the same sentence followed by evidence of what the system is permitted to answer from and a log of what it actually answered.
What to require of an auditable AI knowledge management platform
The specification that follows is what lets a compliance function evidence rather than assert. It is deliberately about platform capability, not vendor assurances, because an auditable AI knowledge management platform makes the evidence a by-product of normal use instead of a project.
| Requirement | What to ask for |
|---|---|
| Answer-level record | For any past answer: the query, the response, the documents cited, and their versions at that moment |
| Source eligibility | Answers restricted to an approved document set, with a named approver and date per document |
| Version discipline | A superseded document stops informing answers immediately, and the record of what was canonical when is retained |
| Export | Logs exportable in a form an internal auditor or counterparty can read, without vendor assistance |
| Provider documentation | The vendor's own technical documentation and its declared scope, supplied at diligence rather than promised |
| Role clarity | A written statement of which obligations the vendor carries as provider and which remain with you as deployer |
The distinction worth holding onto across that table is between a system that can be audited and one that produces its own audit record. Most tools can be audited in the sense that data exists somewhere. Far fewer make reconstruction a lookup, and that difference is what a compliance function feels on the day someone asks about an answer given eight months ago.
How AnswerVault addresses this
AnswerVault is a governed AI knowledge layer that connects an organisation's existing document sources, including SharePoint, Google Drive, and Confluence, and delivers source-backed answers through web chat, Microsoft Teams, Slack, CLI, and API.
It is built so that the three questions above have structural answers. A document becomes eligible for AI answers because a named subject-matter expert approved it, with the approval and its date written into the audit trail when it happens, which is the recorded human decision the oversight expectation is reaching for. Every query, answer, and cited source is logged, and citations resolve to specific document versions, so reconstructing a past answer is a lookup rather than a correlation exercise. When a document is superseded it stops informing answers immediately, and the record of which version was canonical on which date is preserved.
On the vendor side of the diligence, Catapult CX Ltd, AnswerVault's operating entity, is certified to ISO 27001 alongside ISO 9001 and ISO 20000; AnswerVault is G-Cloud listed, and its ISO 42001 certification is underway. The procurement-grade detail a questionnaire response needs, including subprocessors, attestations, and audit rights, is set out on our security and compliance page so a legal team can check it rather than take an assurance.
Where to start
Before answering the questionnaire, do the classification properly: write down what the system does, which decisions its answers inform, and whether your firm is provider or deployer. That single page converts an open-ended compliance question into a bounded one, and it is the document you will reuse every time a client asks.
Then ask your candidate platforms for one thing: reconstruct an answer from three months ago, with its sources and their versions. A platform that can do that in front of you has met the substance of the Act's evidence expectations whatever its risk classification turns out to be. For the wider regulatory picture across DORA, the EU AI Act, and the ISO 42001 AI management standard, our guide to DORA compliance for AI knowledge management is the place to start.
AnswerVault's Starter tier is free: connect a document source and see how a governed, fully logged answer behaves before it reaches a compliance assessment. Get started with AnswerVault.
AnswerVault is built by Catapult CX, an enterprise technology consultancy. The product was originally developed for a global pharmaceutical company with strict data governance requirements, and the same architecture now powers the SaaS platform.