AI automation for finance and ICT providers: organise answers and evidence

Document work is a practical first use of AI in financial services: locating a control record, drafting a questionnaire answer and identifying missing supplier information. These tasks can have specified sources and approvers. Their results can also be compared with the existing manual process.

A financial entity may hold relevant information across contracts, supplier registers, tickets and security documents. An ICT provider faces a similar problem when another customer questionnaire arrives. A long form does not justify generating answers from a model's general knowledge. A statement that a control operates needs current evidence covering the service in question.

This guide addresses documentation, supplier risk and internal procedures. It does not describe automated creditworthiness assessments, investment decisions or a complete DORA implementation programme. Legal requirements have source references. The proposed working method and pilot are author recommendations to adapt to the organisation.

One workflow from two sides

For a financial entity, an assistant can assemble information about an ICT service: the contracted scope, supported function, processing locations, subcontractors and contract owner. It can highlight unanswered questions and inconsistent documents. The authorised people still assess risk and decide whether to accept the supplier.

For an ICT provider, a useful starting point is a questionnaire draft based only on approved records. Each answer should identify its evidence, coverage and date. If a question covers every service but the available record concerns one service, the assistant should show that limit. Expanding a statement beyond its evidence can create contractual exposure.

Start with reading and drafting on both sides. Sending an answer, changing a register and accepting risk are separate actions. Add permissions and approval rules for them only when a demonstrated need exists. More autonomy does not repair inconsistent source documents, and it can make those inconsistencies harder to see.

DORA does not transfer accountability to AI

DORA covers specified financial entities, subject to its scope and exceptions. A financial entity remains responsible for its obligations when using external ICT services. Article 28 addresses ICT third party risk management, assessment before contracting and the register of information concerning ICT contractual arrangements. [1]

Article 30 sets out contractual elements, including the service description, locations, data protection, data access and return, incident assistance and termination rights. Services supporting critical or important functions have additional requirements. Assess the function a service supports before applying an undifferentiated questionnaire to every supplier. [1]

An ICT provider does not become a financial entity simply by supplying a bank. It may face contractual requirements from the customer, while designated critical ICT providers have a separate oversight framework. Therefore, a broad statement that a company has DORA compliance is insufficient. Identify the entity, service, role and particular obligation being addressed.

The GDPR continues to require assessment of personal data, purpose, lawful basis, processor arrangements and security. [2] Under the AI Act, searching procedures is a different intended use from evaluating a natural person's creditworthiness or specified risk and pricing assessments in life and health insurance. A chatbot in the financial sector is not automatically high risk. [3]

NIS2 can also cover particular ICT entities and services. For financial entities, the relationship with DORA as sector specific legislation matters. Check the activity, role and national implementation instead of combining duties from two unrelated checklists. [4] This guide is a preparation method; detailed reporting rules and implementing measures require a separate review when they affect the project.

Establish evidence for each statement

Security questionnaires often mix a policy, an operational fact and a contractual promise. They need different evidence. A backup policy does not prove that the latest backup of a particular system succeeded. A report from one recovery test does not establish the same recovery time for every service.

Record the evidence type, service, coverage, date and owner for each answer. A missing record should create an enquiry rather than a positive declaration. Older evidence can be flagged for review under the organisation's own rules. There is no single universal expiry date for all security documents. Do not allow the model to invent certificates, audits or dates absent from the source.

Useful evidence statuses include confirmed in the source, requiring clarification and outside scope. These statuses describe the available information; they do not constitute risk acceptance. The approver can then see which answers are ready and which require the control owner's response.

Keep a distinction between a supplier's assertion and evidence inspected by your own organisation. For example, an attestation received by email should remain attributable to the supplier. The assistant should not transform it into a statement that your team independently tested the control. That distinction matters when someone later reviews the decision trail.

Define data access and decision rights

The following matrix is a proposed operating arrangement. Agree it before connecting documents or tools.

Do not expose secrets, complete transaction datasets or an entire customer environment because a connector makes it convenient. Questionnaire work usually needs an approved control description and evidence with appropriate coverage. A penetration test report may contain information that cannot be shared with every recipient.

Enforce restrictions in document retrieval and indexing as well as the visible interface. One customer's employee must not retrieve another customer's material by rephrasing a question. Check permissions before content enters the model context. Instructions inside a prompt are too weak to serve as the sole access boundary.

Keep API and MCP controls outside the model

Expose a limited set of operations: read an approved document, read specified register fields, create a draft answer or prepare a ticket. Each tool should check the role, data scope and parameters. The technical account should have permissions matching those operations. The model must not be able to enlarge its own authority through a subsequent request.

A supplier document or questionnaire can include instructions to reveal information, ignore restrictions or invoke a tool. OWASP describes this mechanism as prompt injection. [5] The document remains input data even if it claims administrative authority or urgency. Application controls must reject an operation outside the permitted scope.

Before writing, show the difference between the current and proposed value. Use an idempotency key enforced by the component performing the write so a network retry does not create duplicate tasks. A correlation identifier alone does not prevent duplicates. These are design recommendations. Their purpose is to contain errors and make events traceable, rather than to accumulate controls that nobody understands.

Agree dependencies and terms before launch

Map the processing chain: application, model, document index, logs and subcontractors. Check locations, provider use of data, retention, service change obligations and evidence availability. A regional setting for one component does not establish the location or contractual treatment of the entire service.

If the service supports a critical or important function under DORA, assess the relevant additional contractual and operational requirements. [1] Adding AI does not by itself decide that classification. Consider what would stop working at the financial entity if the application or a dependent provider became unavailable.

Describe the manual fallback, incident procedure and export arrangements in the service scope. Do not promise unrestricted autonomy, guaranteed compliance or a particular retention arrangement without support from the actual configuration and contract. Unsupported promises tend to reappear in the next customer's questionnaire as if they were established facts.

Connect requirements, actions and learning

Pulsar GRC is being developed in early access to support work with customer documents, requirements, controls, risks, actions and evidence. A useful relationship in this setting connects a customer question to its requirement, control, evidence and owner. Confirm the necessary functionality and integration scope before implementation.

Zmianowo/CrewShift is being developed for document based learning and tests with human approval. After confirming the available scope, it can support preparation for a revised supplier assessment or incident procedure. A test result is not an official qualification and does not establish that an employee can handle a real incident unaided.

Responsibility remains explicit: the control owner confirms the state of the control, an authorised person accepts the answer, and technical staff manage the agreed configuration. Software helps organise the work. It must not turn a missing record into a statement that a requirement has been met.

Pilot one questionnaire and one service

Start with a previously completed questionnaire, several dozen questions and documentation for one service. This is an organisational proposal, not a DORA requirement. Prepare reference answers and mark the questions that previously needed clarification. Remove unnecessary personal data and material subject to disclosure restrictions.

Include questions with no evidence, obsolete records, conflicting descriptions and requests outside the user's access rights. Evaluate whether the evidence supports both the answer and its declared scope. An affirmative answer based only on a future implementation plan is a material defect, even if the text sounds reasonable.

Measure preparation time including correction, answers accepted without amendment, correctly identified gaps and unauthorised operations. Faster generation is of little value if review takes longer. Compare similar tasks rather than an easy AI assisted form with a difficult manual one. Define a stop condition before starting, such as unauthorised disclosure or a material unsupported declaration.

NIST AI 600-1 can help select generative AI risks for evaluation. It is voluntary guidance rather than a compliance certificate. [6] Use the resulting risk list to decide what evidence the pilot must produce and which failures would make the proposed scope unacceptable.

A fictional financial sector supplier example

This scenario is fictional. An ICT company receives a questionnaire about one service. It has a backup policy, a recovery report and a subcontractor description. The assistant locates relevant evidence and prepares a draft. Two questions concern areas absent from the documents. Instead of affirmative answers, two enquiries are assigned to control owners.

Security staff check coverage, legal staff assess commitments, and the service owner approves the final response. Only then is it sent to the customer. This is not a Brillnet deployment result. It illustrates the workflow and the points at which people make decisions.

The evaluation should also capture the cost of maintaining sources. Someone needs to update the approved service description after a provider or location changes. Count that effort in the total business case. An assistant that produces quick answers from stale evidence can reduce visible processing time while increasing hidden operational risk.

Prepare for incidents and exit

After an unauthorised read or write, stop the affected integration, preserve necessary logs and determine the extent of the event. The responsible person activates the organisation's assessment under its procedures, contractual duties and applicable law. DORA, GDPR and NIS2 have their own scopes and rules; not every event triggers every reporting route. [1][2][4]

Agree export of documents, answers, relationships and evidence before launch. Check whether approved records remain usable after disconnecting the model. Specify revocation of technical accounts, handling of remaining copies and confirmation that exit actions were completed. Exit belongs in the initial service design, rather than being postponed until a contract ends.

Bring the process to the first discussion

Before launch, Brillnet agrees tool scope, roles, data and exit arrangements. Prepare a sample questionnaire without confidential material, the available source list and the current response effort. Identify the person authorised to accept the statements. These details make it possible to assess feasibility and the cost of automation.

Send your process description to Brillnet. For requirements and evidence, explore Pulsar GRC. For learning based on procedures, explore CrewShift. An implementation is useful when it reduces total work while preserving the reliability of its answers.

Sources

Verified on 2 October 2026. Assess the regulatory scope and detailed requirements for the particular entity and service. The pilot and example are author proposals.

1. DORA — Regulation (EU) 2022/2554, Articles 2, 28–31 and 64. EUR-Lex; accessed: 2026-10-02.
2. GDPR — Regulation (EU) 2016/679, Articles 5, 6, 28 and 32–35. EUR-Lex; accessed: 2026-10-02.
3. AI Act: intended purpose and risk classification and current consolidated Regulation (EU) 2024/1689. European Commission and EUR-Lex; accessed: 2026-10-02.
4. NIS2 — Directive (EU) 2022/2555, Articles 2, 4, 21 and 23 and annexes. EUR-Lex; accessed: 2026-10-02.
5. OWASP LLM01:2025 — Prompt Injection. OWASP GenAI Security Project; accessed: 2026-10-02.
6. NIST AI 600-1 — Generative Artificial Intelligence Profile. NIST; accessed: 2026-10-02. Voluntary guidance, not EU law.