The immediate decision is to keep training disabled. The parties can then assess whether a defined bank-specific improvement fits the service, or whether a separately authorised training use can satisfy the additional requirements.
Executive Summary
- A supplier processing customer data on the bank’s behalf must follow documented instructions. Choosing its own training purpose changes its role for that operation; calling it a processor in the contract does not preserve that status. (GDPR, Articles 4(7)–(8) and 28(3), (10).)
- The bank’s commercial permission does not establish an individual’s consent or another lawful basis. Morocco also requires prior CNDP authorisation for processing personal data for a purpose different from collection. (GDPR, Articles 5–7; Moroccan Law 09-08, Articles 4 and 12(1)(b).)
- Irish hosting does not resolve the transfer question if the separate Moroccan supplier can access personal data. Confidentiality and contractual use restrictions also require their own assessment. (GDPR, Articles 44–46; EDPB Guidelines 05/2021, section 2.)
- Removing names or deleting a prompt file does not establish that a dataset or model is anonymous. Before permitting reuse, the bank needs evidence about retained inputs, embeddings and affected model versions, together with an enforceable removal process. (GDPR, Articles 4(1), 17 and 28(3)(g); EDPB Opinion 28/2024, paragraphs 38–48.)
The proposed training use needs a separate decision
The first contract amendment should define the activity the vendor actually proposes. Retaining a short-lived log to diagnose a bank-reported fault differs from building a reusable training corpus. Fine-tuning a segregated model solely for the bank can differ from improving a model supplied to other customers. Each operation needs its own purpose, data categories, recipients and retention rule.
The bank and vendor should map the complete flow: customer information enters a prompt; the service processes it; outputs, logs or feedback may be retained; selected records may enter a training set; training may produce checkpoints, adapters or other model changes. Any external model provider, support team or cloud service belongs in that map. This identifies the processing the agreement must control. (GDPR, Articles 5(1)(b)–(e), 28(3) and 30.)
The recommended default is no reuse for the vendor’s own development. A bank-specific evaluation or tuning project can proceed only after the bank defines its purpose and instructions, and the parties clear the applicable processing and transfer requirements. Wider training needs a separate agreement supported by the substantive permissions discussed below. A broad “improve our products and services” licence supplies neither the missing lawful purpose nor a sufficient operational boundary.
The vendor’s role follows the purpose of each use
For bank-controlled customer processing, the supplier can be a processor when it acts on the bank’s behalf. If it selects a new purpose of improving its own general model, it acts as controller for that use. GDPR Article 28(10) recognises that consequence where a processor determines purposes and means contrary to the Regulation; it does not authorise the departure from instructions. Joint control requires actual joint determination, rather than the bank merely signing a permission clause. (GDPR, Articles 4(7)–(8), 26 and 28; EDPB Guidelines 07/2020, paragraphs 70–81.)
The vendor’s direct GDPR exposure requires a separate territorial assessment. A Moroccan business does not become directly subject to every GDPR controller duty simply by selling to an Irish bank. Its relevant EU establishment, offering to individuals in the Union or monitoring of their behaviour must be examined. The bank’s GDPR duties and binding processor or transfer terms remain relevant even where the vendor’s own processing falls outside Article 3. (GDPR, Articles 3, 28 and 44–46.)
The bank must establish that its disclosure and further use are lawful. Unless a new valid consent or qualifying Union or Member State law supports the further processing, Article 6(4) requires a compatibility assessment. That assessment considers the relationship between purposes, collection context, data sensitivity, consequences and safeguards. A compatible purpose may continue under the original basis; an incompatible purpose cannot be cured simply by relabelling the vendor’s commercial interest. (GDPR, Articles 5(1)(b), 6(4) and recital 50.)
Where GDPR applies directly, the vendor must establish its own Article 6 basis for its controller processing. The vendor’s contract with the bank is not a contract with each affected individual under Article 6(1)(b). Nor is the bank’s opt-in the consent of customers, employees or other people mentioned in prompts.
Legitimate interests can support some AI processing, but require a specific lawful interest, necessity and a favourable balance against individuals’ rights. Broad reuse of confidential banking narratives presents substantial obstacles: customers may not reasonably expect it, less intrusive data may suffice, and consequences can be serious. The parties must assess those factors against the proposed dataset and model. Consent is another possible route only where it meets the conditions for informed, specific, freely given and withdrawable consent. (GDPR, Articles 6(1)(a), (f) and 7; EDPB Opinion 28/2024, section 3.3.)
Financial data are not automatically special-category data. Prompts may nevertheless reveal health, religion or other Article 9 information, requiring an additional condition; criminal-offence information has separate Article 10 rules. The AI Act’s current Article 4a permits tightly conditioned processing for bias detection and correction. General product improvement cannot be assumed to qualify, and the exception includes restrictions on other parties’ access. (GDPR, Articles 9–10; Regulation (EU) 2024/1689, Articles 2(7) and 4a, as amended by Regulation (EU) 2026/1744.)
The responsible controllers must also provide the required information about the new purpose before further processing and establish rights-handling arrangements. The vendor must assess its own indirect-collection notice duties. Assess whether the use requires a data protection impact assessment; consult the supervisory authority if high residual risk remains. (GDPR, Articles 13(3), 14, 15–22 and 35–36.)
Moroccan law adds its own conditions. The vendor’s own-purpose processing requires compliance with Law 09-08, including its lawful-processing rules. Article 12(1)(b) requires prior CNDP authorisation for personal-data processing for a purpose different from collection. An updated declaration or bank signature alone is insufficient. Even bank-specific tuning can trigger that requirement if it changes the collection purpose. (Law 09-08, Articles 1(5)–(6), 3–4, 12 and 23–26.)
Bank confidentiality and Moroccan access impose separate limits
The bank must check whether customer confidentiality permits the proposed disclosure and use. The Central Bank of Ireland’s INBS inquiry decision recognises the banking-confidentiality duty, its relevance to third-party recipients and its non-absolute character. That administrative decision concerned confidential loan evidence; it does not establish an unrestricted permission for supplier training. Customer authority or a relevant legal exception must cover the actual use. (INBS Inquiry, Module 1 public/private hearing decision, 2 July 2020, paragraphs 12–16.)
Confidentiality can protect commercial information even when no identifiable individual remains. Existing no-training or purpose restrictions must therefore be checked separately. If information qualifies as a trade secret, Irish law also addresses use that breaches confidentiality or contractual use limits, subject to its statutory exceptions and applicable jurisdictional rules. Anonymisation does not itself release those restrictions. (European Union (Protection of Trade Secrets) Regulations 2018, S.I. No. 188/2018, regulations 2(2), 3, 5(2)(b)–(c) and 6.)
The data may move in the opposite direction from the commercial service. Personal data disclosed by the Irish bank to a separate supplier in Morocco engage GDPR Chapter V. Remote access can constitute that disclosure even when the servers remain in Ireland. Morocco has no European Commission adequacy decision, so the parties need an applicable transfer route and its safeguards. (GDPR, Articles 44–46; EDPB Guidelines 05/2021, section 2.)
For transfers covered by the 2021 standard contractual clauses, controller-to-processor Module 2 fits service processing; controller-to-controller Module 1 fits a separately permitted vendor-controller use. The parties must check the importer’s territorial position first. Decision (EU) 2021/914 covers importer processing outside GDPR Article 3. If the relevant importer processing is directly subject to GDPR, those clauses are not the applicable ready-made instrument; another valid Chapter V route is required. (Decision (EU) 2021/914, Article 1(1), Annex Modules 1–2; Commission SCC FAQ, question 24.)
An SCC signature is only part of the work. The bank and vendor must assess the actual recipients, access arrangements, relevant Moroccan laws and practices, public-authority access and available remedies. Where necessary, effective supplementary measures must address the identified risks. Encryption in transit or storage does not solve an access problem if the vendor must read the data and the relevant authorities can obtain it. If effective protection cannot be assured, suspend or redesign the affected transfer. Routine training should not depend on an unexplained Article 49 derogation. (SCCs, clauses 14–16; EDPB Recommendations 01/2020, Annex 2, Use Cases 6–7.)
Moroccan compliance covers the local processing and any onward transfer. The bank must assess whether using Moroccan processing means brings it within Law 09-08’s foreign-controller provisions, including local representation. Applicable CNDP processing formalities must be evidenced. Personal-data outputs returned from Morocco to Ireland, and disclosures to other foreign providers, require a separate Moroccan transfer assessment. Ireland appears on the CNDP sufficient-protection list, but notification requirements remain. That listing does not establish EU adequacy for Morocco. (Law 09-08, Articles 2, 12–21 and 43–44; Decree 2-09-165, Articles 46–50; CNDP Decision 236-2015, Article 1.)
Removing identifiers does not establish anonymity
Deleting names, replacing account numbers or retaining embeddings changes the technical representation. It does not establish that people can no longer be identified. Prompts may contain distinctive transactions, rare events or combinations that link back to bank records. Embeddings and synthetic records may preserve recoverable or linkable information. Their legal status requires evidence about the relevant data and available means of identification. (GDPR, Article 4(1), (5) and recital 26; Law 09-08, Article 1(1).)
The recipient’s position matters. In EDPS v SRB, the Court held, under the parallel EU-institutions regime, that pseudonymised information is not necessarily personal data for every recipient. The assessment considers the recipient’s reasonably available means. It does not remove the originating controller’s obligations or establish anonymity for a vendor retaining source material, mappings or access to bank records. (Case C-413/23 P, EU:C:2025:645, paragraphs 68–89 and 100–115.)
An AI model needs its own assessment. The EDPB asks whether the likelihood of extracting personal data, including probabilistically, and of obtaining it through queries is insignificant, considering reasonably likely means. The vendor should document the model version, training provenance, access conditions, auxiliary information and relevant extraction, memorisation and linkage tests. A claim of anonymity must survive the intended release conditions, including access to weights where applicable. (EDPB Opinion 28/2024, paragraphs 38–58.)
The bank should require that evidence before accepting an anonymous-data reuse exception. Anonymisation itself must have a lawful basis while personal data are processed. A later anonymous model does not retrospectively legalise its training, and contractual confidentiality can continue. (GDPR, Article 6; EDPB Opinion 28/2024, section 3.4.) The separate analysis of synthetic data supplied to an Irish bank explains the supply question; here the additional decision is whether the vendor may repurpose the bank’s actual inputs.
Make the permitted use enforceable in the contract and product
The bank’s legal and procurement teams should put the service-only decision into the DPA and MSA. Define the protected material to include prompts, retrieved documents, outputs, feedback and logs, with express treatment of embeddings and learned artifacts. Permit only specified service operations. Prohibit own-model training, cross-customer datasets and onward reuse unless separately authorised. Remove conflicting feedback, residual-knowledge or product-improvement licences. These are proposed contractual controls implementing the agreed boundary; GDPR does not prescribe a clause named “no training”. (GDPR, Articles 5, 25 and 28.)
The vendor’s engineering lead should then disable training and dataset ingestion for the bank tenant, restrict support access and verify corresponding settings and terms for upstream providers. The DPA should identify authorised subprocessors and the procedure for changes. The bank should accept the configuration evidence before service use; the processing, confidentiality and transfer requirements must also be satisfied. The broader AI supplier contract review covers the surrounding customer agreement and procurement documents.
For bank-specific evaluation or tuning, require a written change order stating the bank’s purpose, permitted records, model version, access, retention and ownership or use rights in resulting artifacts. Keep resulting materials segregated and prohibit other-customer use. The bank should approve the project only after its privacy assessment, applicable CNDP formalities and transfer controls are complete. Processing can remain on the bank’s behalf where the bank actually determines its purpose and essential means.
If the vendor seeks its own training purpose, keep the prohibition in place until a separate controller-use arrangement is effective. The bank and vendor must each document their applicable lawful-processing analysis; resolve confidentiality authority, notices, rights and sensitive-data conditions; complete required CNDP authorisation; and implement the correct transfers. The bank’s accountable business owner should decide whether to accept the residual commercial risk, with legal, security and data-protection input. Contractual approval cannot replace any statutory condition.
Delete retained inputs and copies
The retention schedule should give each store a purpose, owner, deletion trigger and verified maximum period. It must cover prompts, outputs, training corpora, evaluation sets, feedback, logs, vector stores and backups. The vendor should supply deletion records, downstream confirmations and evidence of backup retirement. Restricted backup copies must remain unavailable for ordinary use and training while awaiting their defined deletion cycle. A backup cycle cannot override an applicable deletion duty.
At the end of processor services, GDPR Article 28(3)(g) requires return or deletion at the bank’s choice and deletion of copies, unless Union or Member State law requires storage. Purpose-based retention limits and applicable individual rights can require earlier action. Any genuinely applicable retention duty must be identified and confined to its purpose; it supplies no training permission. (GDPR, Articles 5(1)(e), 17 and 28(3)(g).)
Address model-derived material separately
The vendor should maintain lineage from bank inputs to datasets, embeddings, checkpoints, adapters and released models. Deleting source files does not prove that personal information has left those artifacts. Conversely, every model weight is not automatically personal data.
Where personal data remain, assess the applicable erasure, restriction or objection request and any actual exception. The contract should require a verified remedy, which may involve rebuilding an index, effective unlearning, retraining or withdrawing an affected model. Output filtering alone does not demonstrate erasure. Technical difficulty is not a standalone GDPR exemption. If the vendor cannot demonstrate a compliant response to foreseeable rights requests, the bank should decline that reuse design. Separately, the parties can prohibit retention of bank-derived models even where those models are nonpersonal. (GDPR, Articles 17–21 and 25; EDPB Opinion 28/2024, sections 3.2 and 3.4.)
For a bank covered by DORA, the continuing AI service also needs the required ICT contract terms. These include service and processing locations, data confidentiality, recovery and return, incident assistance, authority cooperation and termination. Services supporting critical or important functions require additional oversight and exit provisions. The bank must classify the supported function and align the agreement accordingly; those obligations confer no training permission. (Regulation (EU) 2022/2554, Articles 2(1)(a), 3(21)–(22), 28 and 30, applicable since 17 January 2025.)
Licentium can review the permitted data uses, allocation of roles, and DPA, MSA, transfer and deletion terms needed for the proposed arrangement. Review customer-data and training terms.