Ask a general-purpose chatbot a regulatory question and you get a fluent answer. Ask where it came from and you may get a document name. Ask for the exact sentence behind it and, more often than not, the trail goes cold. In compliance, that last step is the only one that counts.
_Summary
When a compliance team tests a new AI tool, the first impression comes from the answers. They read well, sound confident and arrive in seconds. The second impression comes later, often in front of an auditor, when someone asks a simple question: where does this answer come from? If the tool cannot point to the document, the page and the passage, the answer has to be rebuilt by hand. The time the AI saved is spent again, and then some.
That gap has little to do with how smart the model is. A general-purpose chatbot, even one built on an excellent model, is designed to answer anything for anyone. AI built for regulatory compliance is designed to answer a narrower set of questions in a way that can be checked. This article explains, in plain language, what that difference looks like under the hood.
What makes AI trustworthy in regulatory compliance?
In regulatory compliance, trusting an AI answer does not mean believing it. It means being able to check it, today by the person who validates it and months later by an auditor. That kind of trust rests on two properties:
- Transparency means the AI shows how it reached a result: which data, which rule, which source.
- Auditability means a third party can follow that path afterwards and verify it, without having to trust the system.
The two are related, but not the same. A system can explain itself in general terms and still leave no record an auditor can test. In regulatory compliance you need both: the person validating an answer needs transparency in the moment, and the auditor needs a trail that still holds months later.
How does a generic chatbot answer a compliance question?
Take a familiar scenario. A compliance analyst uploads a counterparty’s annual report to a general-purpose chatbot and asks whether it discloses Scope 3 emissions. The chatbot says yes and gives a figure. Asked for the exact passage, it may quote a sentence that is paraphrased, comes from another section, or does not contain the figure at all.
This is not a flaw of one particular model; it is how generic chatbots work. They do not look answers up in a database. They draw on three things:
- Training: patterns learned from huge volumes of text, stored as statistical weights rather than as facts the model can point to.
- The conversation: your messages and uploaded files, read as language rather than as data fields.
- Tools, when used: a web search or a file search that pulls in relevant passages.
The answer is then written freely from all of this. Some chatbots attach sources, but nothing guarantees that each sentence is supported by the source next to it. In a 2023 Stanford study of four generative search engines, only 51.5% of generated sentences were fully supported by their citations, and only 74.5% of citations supported the sentence they were attached to. The answers users found most fluent tended to have the weakest citations (Liu, Zhang & Liang, Findings of EMNLP 2023). Models have improved since, but the way they produce answers has not changed.
A stronger model writes a better answer, but it writes it the same way: evidence is optional, not built in.
How do a generic chatbot and a specialised AI answer your question?
Structuring means turning messy material into a defined shape before any question is asked. For example, every counterparty, contract date and amount is extracted from 500 PDFs into a table with fixed fields, and each value stays linked to the page it came from. Questions are then answered from that table, with the AI translating the question into the right lookup and drafting the answer around the result.
| Answering directly from text (generic chatbot) | Structuring first, then answering (specialised AI) | |
|---|---|---|
| Setup | None: just ask | Upfront work: schema, extraction, validation |
| Flexibility | Can attempt any question, including nuanced or ambiguous ones | Strongest on the questions the data was organised for; others need a fallback, such as search over the source text |
| Exact counts, sums, filters | Unreliable at scale; items can be missed or invented | Calculations are exact and repeatable, but only as accurate as the extracted data |
| Consistency | The same question can get slightly different answers | The underlying values stay the same; only the wording of the answer may vary |
| Auditability | Sources can be cited, but citations often do not support the statement | Each value can trace back to its document and page, if the system records that link |
| Where errors come from | Misreading, overlooking or inventing content while answering | Mostly the extraction step; a wrong value repeats in every answer until a reviewer corrects it |
| Scale | Limited by how much text the model can read at once, and accuracy drops well before that limit | Thousands of documents, millions of records |
For regulatory compliance, the trade-off is clear. The structuring work is done once; precision, consistency and traceability pay off in every reporting cycle and every questionnaire that follows.
What makes AI specialised for regulatory compliance?
A specialised system can run on the same kind of language model as a chatbot. What changes is everything built around the model, starting with the knowledge it answers from. In plain terms, five layers make the difference:
- It knows the rulebook. Regulations, delegated acts and technical standards are digitised and organised in advance, so the AI works from the actual regulatory text rather than from what it absorbed in training.
- It builds a knowledge base unique to the job. Before answering anything, it builds a dedicated knowledge base from your own documents and the regulations that apply to you, shaped around the specific task it has to solve, whether that is an ESG questionnaire, a due diligence request or an EU Taxonomy report. Documents are turned into defined data fields, such as an emissions figure, a contract date or a certification, and every value keeps a link to the page it came from.
- It knows what each question needs. Questionnaire templates map each question to the data fields and regulatory requirements behind it, so the same question gets the same answer every time.
- It knows when it is unsure. Answers with weak or missing evidence are flagged instead of filled in confidently, and routed to a person for review.
- It runs in a controlled environment. Logs, versions and human decisions are recorded, and client data stays isolated and is never used for training.
Structuring does not make errors disappear; it moves them to the extraction step. A value extracted wrongly stays wrong in every answer that uses it, and research on retrieval-based systems shows that when the retrieved information is insufficient, models tend to answer anyway rather than say “I don’t know” (Google Research, ICLR 2025). That is why layers 4 and 5 matter as much as the model itself: every value needs its source attached, and a human who validates what the system flags.
A generic chatbot is built to give a good answer on any topic. A specialised system is built to give a verifiable answer on one. We looked at what this means for accuracy in Generic AI vs. specialized AI.
Why does transparency matter so much in regulatory reporting?
Because regulatory reporting runs on evidence, not on plausibility. The ECB’s Guide on effective risk data aggregation and risk reporting expects banks to maintain complete and up-to-date data lineage at the data attribute level, from data capture through extraction and transformation to the final report, so that figures can be traced for external validation (ECB Banking Supervision, May 2024). Under the CSRD, sustainability statements are subject to limited assurance by a statutory auditor or independent assurance provider (Directive (EU) 2022/2464), which in practice means every reported figure needs a documented source.
The EU AI Act turns these expectations into explicit design requirements. For AI systems classified as high-risk, it requires four things:
- Records (Article 12). The system must automatically log events over its lifetime, so that its functioning can be traced and monitored (Article 12).
- Interpretable output (Article 13). It must be transparent enough for the people using it to interpret its output and use it appropriately, and come with instructions that explain its capabilities, its limitations and the tools available to explain its results (Article 13).
- Effective human oversight (Article 14). The people assigned to oversee it must be able to understand what it can and cannot do, stay aware of the risk of over-relying on its output (automation bias), interpret its results correctly, and decide to disregard, override or reverse them (Article 14).
- Oversight in practice (Article 26). Organisations using such a system must assign oversight to people with the necessary competence and authority, and keep the logs it generates for at least six months (Article 26).
Which systems count as high-risk is set out in Annex III. In financial services this covers, for example, credit scoring of individuals and risk assessment and pricing in life and health insurance. Most AI used for regulatory reporting or questionnaire answering does not fall into that category. Following the Digital Omnibus, the requirements for Annex III systems apply from 2 December 2027 (Regulation (EU) 2026/1744). Even where they do not formally apply, these four requirements describe what auditors and supervisors will look for in any AI that touches regulated data: logs, interpretable output, and a human who can say no.
In Switzerland, FINMA’s Guidance 08/2024 on governance and risk management when using AI names explainability, documentation and independent review among the areas it examines in supervised institutions (FINMA, December 2024).
An answer without a source is a risk that moves downstream: from the AI to the analyst, from the analyst to the report, and from the report to the auditor.
How does auditability give security to the people validating AI answers?
Human control is only as good as the information the human has. A reviewer who sees an answer without its evidence has two options: trust it, or redo the research. Neither is real validation.
When every answer arrives with the document, the page and the passage it was taken from, the reviewer’s job changes. They no longer search; they check. A correct answer is confirmed in seconds, a wrong one is caught before it reaches a report, and every decision to accept, adjust or override is recorded. For the auditor, that same trail becomes the evidence file.
Auditability is what turns “human in the loop” from a promise into a control.
How does DYDON AI achieve auditability in practice?
We built our Automatic Questionnaire Answering on the opposite principle to a chatbot: the evidence comes first, and the answer is built on it.
It starts with structured data, not with a prompt
Our Intelligent Document Processing extracts data from thousands of documents into one central Data Collector. Every extracted value keeps its link to the source document, the page and the extraction timestamp.
Every answer carries its evidence
When a questionnaire arrives, whether an ESG rating form, a due diligence request, an LkSG supplier assessment or an OEM audit, the AI maps each question to your validated data and drafts a regulation-aware answer with its source reference attached. A compliance answer is not just “Yes.” It is “Yes, because clause 4.2 of document X states…”. Nobody has to ask twice.
Your experts keep the final word
Low-confidence answers are flagged for review, so your team focuses on the exceptions instead of the whole questionnaire. Reviewers can validate, adjust or override any answer, and every change is part of the audit trail.
Define once, reuse every cycle
Questionnaire templates are configured once and reused across reporting cycles, and answers can be exported or submitted to external portals via API.
All of this runs on open-weight models in a dedicated, isolated environment on European infrastructure. Your data is never used for training, and the audit trail lives where your data lives.
Let’s talk about your use case
Every institution faces different questionnaires, different auditors and different regulations. If you want to see what an evidence-linked answer looks like on your own documents, or check whether your current AI setup would stand up to an auditor’s questions, we’re happy to walk you through it.