Customer AI questionnaire answered

Q1: Is the service a high-risk AI system? It depends on facts we still need to confirm.

• Credit scoring is listed as high-risk. Annex III(5)(b) covers "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score". Recital (58) gives the reason. Annex III systems are high-risk by default under Article 6(2).
• There is a way out. Article 6(3) says an Annex III system is not high-risk if it does not "materially influenc[e] the outcome of decision making". One qualifying condition is performing (a) "a narrow procedural task" or (d) "a preparatory task". Recital (53) gives "an AI system that transforms unstructured data into structured data" as an example of a narrow procedural task. That matches what the service does.
• The way out is blocked if the system profiles people. Under the last subparagraph of Article 6(3), a system "shall always be considered to be high-risk where the AI system performs profiling". GDPR Article 4(4) defines profiling as using personal data to "evaluate… a natural person's… economic situation".
• [FACT] Does the output only extract figures, or does it also flag, score, rank or judge whether an applicant is affordable or consistent? If it does any of the latter, treat the service as high-risk.
• Claiming non-high-risk has its own duties. Under Article 6(4), Skaitis must document the assessment before placing the system on the market. Under Article 49(2), it must register itself and the system in the EU database.
• [FACT] Has that assessment been documented, and has the system been registered?
• Article 25(1)(c) is worth pointing out to the bank. If the bank changes the intended purpose so the system becomes high-risk, the bank becomes the provider.

Q2: What information must you give us as deployer? This applies if the service is high-risk.

• Article 13(3) lists the minimum contents of the instructions for use:
• provider identity;
• intended purpose;
• accuracy metrics;
• known risks;
• input-data specifications;
• how to interpret the output;
• pre-determined changes;
• human oversight measures;
• resources and maintenance;
• log-collection mechanisms.
• Article 13(1) requires the system to be transparent enough for deployers to interpret its output.
• The bank's own duties rely on this information:
• Article 26(1): using the system in line with the instructions.
• Article 26(9): the bank's GDPR impact assessment (DPIA).
• Article 27(1): a fundamental rights impact assessment. This is mandatory for deployers of Annex III point 5(b) systems, so the bank will need our Article 13 information for it.
• [FACT] Accuracy metrics, intended purpose wording, and input specifications (document types, languages, formats).
• If the service is not high-risk, the held text does not require this list. Supplying it would be contractual.

Q3: Does the system keep logs, and for how long?

• If high-risk, Article 12(1) requires the system to record events automatically over its lifetime, for the purposes set out in Article 12(2).
• The provider must keep the logs under its control "of at least six months" (Article 19(1)).
• The bank, as a financial institution, keeps its logs as part of its financial-services documentation (Article 26(6), second subparagraph).
• [FACT] What is logged, where, the actual retention period, and who controls which logs.
• If the service is not high-risk, the held text sets no logging duty.

Q4: How do you support human oversight?

• If high-risk, Article 14(1) requires the system to be designed so people can effectively oversee it.
• Article 14(3) splits oversight measures into those built in by the provider and those the provider identifies for the deployer to carry out.
• Article 14(4)(a)–(e) says the people overseeing it must be able to:
• understand its limits;
• stay alert to automation bias;
• interpret the output;
• disregard or override the output;
• stop the system.
• The bank must assign competent staff to oversight (Article 26(2)).
• [FACT] Describe the actual review screen, confidence flags, the correction workflow, and the stop mechanism.

Q5: Will you accept DORA contract terms, including audit and exit?

• Accepting the terms is a commercial decision for Skaitis. The held text only sets what the contract must contain. Skaitis meets DORA's definition of an ICT third-party service provider, "an undertaking providing ICT services" (DORA Article 3(19)). The bank stays fully responsible for DORA compliance (Article 28(1)(a)).
• The contract must be written (Article 30(1)). For every ICT service it must include (Article 30(2)(a)–(i)):
• a description of the services and subcontracting;
• data locations;
• data protection;
• access to and return of data on insolvency or termination;
• service levels;
• incident assistance;
• cooperation with the authorities;
• termination rights and notice periods;
• training participation.
• If the service supports a critical or important function, Article 30(3) adds more:
• full service levels;
• business-continuity plans;
• taking part in the bank's threat-led penetration testing (TLPT);
• unrestricted access, inspection and audit rights for the bank and the competent authority (point (e));
• exit strategies with a mandatory transition period (point (f)).
• The bank must also be able to terminate on the grounds in Article 28(7) and must have exit plans (Article 28(8)).
• [FACT] Ask the bank whether it classifies this service as supporting a critical or important function. That is the bank's own assessment under Article 28(4)(a). We also need to supply our data locations and any subcontractors (for example, cloud hosting).

Q6: Are you our processor, and what must the contract contain?

• A processor processes personal data "on behalf of the controller" (GDPR Article 4(8)).
• The contract must set out (Article 28(3)):
• the subject matter, duration, nature and purpose of the processing;
• the types of data and data subjects.
• It must also bind Skaitis to (Article 28(3)(a)–(h)):
• process data only on documented instructions;
• confidentiality;
• security measures under Article 32;
• sub-processor rules;
• help with data-subject requests and with Articles 32–36;
• delete or return the data at the end;
• audits.
• Using sub-processors needs the bank's authorisation (Article 28(2)). Skaitis must notify breaches without undue delay (Article 33(2)).
• [FACT] Does Skaitis use the bank's customer data for its own purposes, such as training its models? If so, Article 28(10) makes Skaitis a controller for that processing, and the answer changes.

1. The output's exact scope: extraction only, or any scoring or judgement. This decides Q1 through Article 6(3) and the profiling override.
2. Whether the Article 6(4) assessment is documented and the Article 49(2) registration done.
3. Accuracy metrics, intended-purpose wording and input specifications, for Q2.
4. What is logged, how long it is kept, and who controls the logs, for Q3.
5. How oversight works in the interface (review, override, stop), for Q4.
6. Data locations, subcontractors, service levels, and continuity and exit arrangements, for Q5.
7. Whether customer data is reused for training or product improvement, for Q6.
8. From the bank: whether it treats this as a critical or important function, for Q5.

• The Commission's Article 6(5) guidelines with high-risk and non-high-risk examples are not held. They could settle whether extraction counts as a "narrow procedural task".
• DORA's detailed technical standards (RTS/ITS) on subcontracting and the register templates, and EBA guidance, are not held.
• National law is not held, including Lithuanian and bank-side record-keeping periods that would set the log retention under Article 26(6).
• Harmonised standards for the AI Act are not held.
• Whether Skaitis will accept particular terms is a commercial decision, not something regulation text answers.

• All 41 pinpoints above exist in the held text, and every quoted passage was found. The list, with quotes checked for most:
• AI Act: Articles 3(3), 3(4), 6(3), 6(4), 12(1), 12(2), 13(3), 14(3), 14(4), 16, 19(1), 25(1), 26(1), 26(2), 26(5), 26(6), 27(1), 49(2); Annex III(5)(b); Recitals (53) and (58).
• DORA: Articles 3(19), 28(1), 28(7), 28(8), 30(1), 30(2), 30(3).
• GDPR: Articles 4(4), 4(8), 28(2), 28(3), 28(10), 33(2).
• A few pinpoints were cited without being passed to verify_citation, but their text was read directly: AI Act Articles 6(2), 12(3), 13(1), 14(1) and 26(9), DORA Article 28(4), and GDPR Article 4(7).
• Neither of the two identifiers the tool returned needs fixing: GDPR Art. 4(4)/(8) and DORA Art. 3(19) resolve to "Article 4/3, amendment (n)", which is how the tool labels definition points.
• The customer's questionnaire cites no articles, so there were none of theirs to check.

I did not record any applicability verdicts with record_assessment. The playbook says to do that only after a compliance officer states applicability, and none was present for this run.