A hypothetical Kenyan AI company wants an EU lender to use its alternative-data creditworthiness score in consumer-loan decisions. Can it start with a limited pilot before preparing for full deployment? The proposed first use is one bank's unsecured, fixed-term personal-loan product for adult existing customers in one designated EU Member State. The proposed system would infer repayment risk from inputs within the AI Act's Article 3(1) definition. The bank would retain the lending decision. Evaluation would begin without customer consequences, in an EU-controlled environment, with no Kenyan access to EU personal data.
Executive Summary
- The company can contract for diligence and a genuinely non-decision evaluation before completing its production package. A small pilot that influences lending requires the legal and operational safeguards applicable to that use. Neither a pilot label nor a free licence creates an exemption. (Regulation (EU) 2024/1689, Arts. 2(8), 3(9)–(12), 60; Regulation (EU) 2016/679, Arts. 5, 6, 22, 35.)
- A system intended to score natural persons' creditworthiness falls within Annex III, point 5(b). Its profiling function defeats the Article 6(3) exclusion, even with human review. The financial-fraud exception does not cover the proposed repayment-risk score. (Regulation (EU) 2024/1689, Art. 6(2)–(3), Annex III, point 5(b).)
- The enacted 2026 amendment changes the timetable. Chapter III, Sections 1–3, apart from Article 6(5), apply to Annex III systems from 2 December 2027. The amended Article 111 transition requires a separate assessment of earlier systems and later design changes. The delay does not suspend GDPR or DORA. (Regulation (EU) 2024/1689, Arts. 111(2), 113, as amended by Regulation (EU) 2026/1744.)
- Historical personal data remains regulated. True anonymisation can remove a dataset from GDPR; replacing names with identifiers does not by itself establish anonymisation. A lender's contractual need to assess credit does not automatically authorise commercial model training or solely automated refusals. (Regulation (EU) 2016/679, recital 26, Arts. 4(5), 6, 22.)
- Kenyan training requires its own provenance review. Commercial use engages section 37, alongside lawful-processing requirements. Kenyan export safeguards do not establish a lawful EU-to-Kenya transfer. The proposed first phase therefore blocks Kenyan access to customer records, support logs and identifiable outputs. (Data Protection Act 2019 (Kenya), ss. 25, 30, 37, 48–49; Data Protection (General) Regulations 2021, reg. 14; Regulation (EU) 2016/679, Arts. 44–46.)
- Under the recommended contract, production starts only after a written phase-release decision ties the approved model to its country, inputs, purpose and decision process. That decision must rest on lawful data use, local validation, functioning review and complaints procedures, required assessments, and the bank's ICT controls. A favourable benchmark alone cannot satisfy those conditions. (Regulation (EU) 2016/679, Arts. 5(2), 24, 35; Regulation (EU) 2022/2554, Arts. 28–30.)
The first product and its contractual boundary
The recommended starting product is a version-locked score for one bank's existing-customer personal-loan applications. It would estimate repayment risk from declared income, expenditure and existing debt, together with narrowly defined first-party financial behaviour. Candidate behavioural features would be income regularity and previous repayment history. Each feature would need a documented reason for inclusion and a lawful source. These are proposed restrictions, not claims about the company's existing model. If the existing model cannot operate lawfully within them, the provider must change the relevant inputs or model before advancement. The changed version would require fresh validation. (Regulation (EU) 2016/679, Arts. 5(1)(b)–(d), 6, 25.)
The initial specification should exclude contact lists, message contents, social-network activity, precise location and raw merchant descriptions. It should prohibit features that reveal health, religion or other protected sensitive information. The bank would retain affordability assessment, product eligibility and the credit decision. The score would not set prices, reject applications, change existing facilities or trigger collections. These limits reduce the number of purposes and affected decisions that the parties must justify. They do not remove creditworthiness profiling from Annex III. (Regulation (EU) 2016/679, Arts. 5, 9; Regulation (EU) 2024/1689, Art. 6(3), Annex III, point 5(b).)
Use an EU bank-controlled environment for inference, records, logs, backups and keys. Kenyan engineers would receive code and synthetic reproductions of faults. The contract should prohibit person-level telemetry, remote database access and live screenshots in support tickets. EU hosting alone does not establish that processing stays inside the EU. The parties must test the support pathway and the model's capacity to expose personal training records. (Regulation (EU) 2016/679, Arts. 25, 28, 32, 44; EDPB, Opinion 28/2024, section 3.2.)
One Member State must be identified in the launch schedule before a personal-data or operational phase. That schedule should identify the lender's authorisation, applicable consumer-credit rules, supervisor and complaints route. Expansion to other countries, applicant populations or lending products should require a new release decision. This contractual limit avoids presenting one bank's assessment as permission for EU-wide lending.
Creditworthiness classification and the 2026 amendment
The proposed function meets the Annex III creditworthiness description. Article 6(3) permits specified low-risk ancillary uses to escape high-risk treatment, subject to its conditions. But an Annex III system that profiles natural persons remains high-risk. Evaluating an applicant's economic situation and likely repayment behaviour is profiling under GDPR Article 4(4). A human making the final lending decision therefore does not establish the Article 6(3) exclusion. (Regulation (EU) 2024/1689, Art. 6(2)–(4), Annex III, point 5(b); Regulation (EU) 2016/679, Art. 4(4).)
A supplier might describe the score as preparatory advice or fraud prevention. The first description fails where the system profiles applicants; the second fails where its intended purpose remains creditworthiness. The fraud exception concerns systems used to detect financial fraud. Instructions, technical design and marketing must describe the actual function. Separating a genuine fraud module would not remove the repayment-risk module from Annex III. (Regulation (EU) 2024/1689, Arts. 3(12), 6(3), Annex III, point 5(b).)
Credit scoring is not automatically prohibited social scoring. Article 5(1)(c) requires the specified evaluation over time and a social score leading to unrelated-context treatment or unjustified or disproportionate treatment. Using social behaviour to deny credit can engage that prohibition when those elements are present. The parties should screen the original feature set before any pilot; a conforming creditworthiness system cannot include a prohibited practice. (Regulation (EU) 2024/1689, Art. 5(1)(c), recital 31.)
The applicable timetable now includes Regulation (EU) 2026/1744, adopted on 8 July 2026 and effective from 27 July 2026. Under amended Article 113, Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027 to Article 6(2) systems. The corresponding date for Article 6(1) product-related systems is 2 August 2028. This stand-alone credit score follows the Annex III route. The original 2 August 2026 date is no longer the correct date for those deferred requirements. (Regulation (EU) 2026/1744, Arts. 1, 4; Regulation (EU) 2024/1689, Art. 113.)
The deferral is confined to the provisions Article 113 identifies. The general application date remains 2 August 2026, with separate earlier and later dates for specified provisions. Article 111(2) addresses high-risk systems placed on the market or put into service before their relevant Chapter III date. Subject to its wording and the Article 5 prohibition, compliance for those systems turns on significant design changes from that date. This is a transitional rule requiring evidence of the system and event concerned. (Regulation (EU) 2024/1689, Arts. 111(2), 113.)
A genuine earlier commercial release may therefore have a different timetable from a system first released after 2 December 2027 that lacks qualifying earlier units of the same type and model. Recital 39 of the amending Regulation clarifies that later units of the same type and model can share the transition where a first unit was lawfully released before the relevant date and the design remains unchanged. A research demonstration does not establish that an operational system was already placed on the market. The parties should preserve the released version, intended purpose, supply date and change history. They should not manufacture a legacy-system claim by renaming a test. For this transaction, building the full high-risk package before decision-influencing use is the recommended contractual standard, even where transitional law does not yet demand every component. (Regulation (EU) 2024/1689, Arts. 3(9)–(12), 111(2), 113; Regulation (EU) 2026/1744, recital 39.)
Provider, deployer and data-protection roles
Current Article 4 requires providers and deployers to take measures supporting the development of staff and other relevant persons' AI literacy. It does not require a guaranteed individual literacy level. The pilot contract should identify the people who need training and the system limitations they must understand. (Regulation (EU) 2024/1689, Art. 4, as amended by Regulation (EU) 2026/1744.)
Selling into the EU can bring the Kenyan company within the AI Act without an EU establishment. Article 2 covers providers placing systems on the EU market and specified third-country actors whose outputs are used in the EU. Under the proposed vendor-branded product, the Kenyan company would be the provider and the bank the deployer. Any importer or distributor role needs separate allocation from the actual supply chain. Hosting location does not decide those roles. (Regulation (EU) 2024/1689, Arts. 2(1)(a), (c), 3(3)–(7).)
White-labelling, substantial modification or repurposing can place provider responsibilities on another actor under Article 25. The contract should allocate access to documentation, known limitations, testing facilities and assistance if that happens. A clause calling the bank the sole decision-maker cannot displace a statutory provider role. Licentium's AI Act readiness assessment addresses system classification, actor roles and obligation dates. (Regulation (EU) 2024/1689, Art. 25(1)–(4).)
GDPR roles require a separate analysis of each operation. The bank would ordinarily control application processing and lending purposes. A vendor processing records solely on documented bank instructions would act as processor for those operations. A vendor choosing to reuse records to improve its own commercial model determines a separate purpose and needs a controller analysis. Joint control requires joint determination; it does not follow merely from cooperation. (Regulation (EU) 2016/679, Arts. 4(7)–(8), 26, 28(3), 28(10).)
The EU lender falls within GDPR's establishment rule. A Kenyan processor does not become directly subject to every GDPR duty solely because its customer is European. Its own establishment, offering or behavioural-monitoring activities require an Article 3 assessment. The lender's Article 28 obligations and the Chapter V transfer requirements remain relevant even where the overseas recipient is not directly subject under Article 3. Any GDPR Article 27 representative duty requires a separate assessment from representation under the AI Act. (Regulation (EU) 2016/679, Arts. 3, 27–28, 44; EDPB, Guidelines 05/2021, version 2.0, sections 2–3.)
Lawful data use and decisions under GDPR
The lender must identify a basis for each processing purpose before it supplies personal records. Article 6(1)(b) requires objective necessity for the applicant's contract or requested pre-contractual steps. Article 6(1)(c) requires an applicable legal obligation. Legitimate interests under Article 6(1)(f) require necessity and a balance against the person's rights. None establishes that every alternative-data feature is necessary merely because it predicts repayment. (Regulation (EU) 2016/679, Arts. 5(1)(c), 6(1), 6(3).)
Historical validation and commercial training require their own purpose analysis. A loan application does not give the vendor unrestricted permission to train a reusable model. The lender must address the original purpose, compatibility where applicable, notices, retention and objection rights. The Article 28 agreement should prohibit independent training, pooling between lenders and product-development reuse unless a separately approved lawful arrangement permits them. (Regulation (EU) 2016/679, Arts. 5(1)(b), 6(4), 13–14, 21, 28(3).)
Article 22 adds a separate condition where a decision is solely automated and has legal or similarly significant effects. Its exceptions concern contractual necessity, authorising Union or Member State law with safeguards, or explicit consent. A legitimate-interests basis alone is not an Article 22 exception. Where contractual necessity or explicit consent is relied upon, Article 22(3) requires safeguards including human intervention, expression of views and contestation. Consent must also meet the freely given, specific and informed requirements in Articles 4(11) and 7. Article 22(4) restricts special-category decisions to the specified Article 9(2)(a) or (g) grounds with suitable safeguards. (Regulation (EU) 2016/679, Arts. 4(11), 7, 22(1)–(4).)
The lender's formal signature does not settle whether a decision is solely automated. In SCHUFA, the Court of Justice held that producing a credit probability value can itself constitute automated decision-making when a third party's contractual decision depends decisively on it. Material influence should prompt examination of the workflow, but it is not a substitute for applying the Court's determining-role test. (SCHUFA Holding (Scoring), Case C-634/21, EU:C:2023:957, operative part, OJ C, C/2024/913, 29 January 2024.)
For the proposed assisted-decision route, a reviewer should examine the financial information independently, understand the score's limitations and possess authority to disregard it. The bank should record reasons for decisions and overrides, then audit whether staff follow scores mechanically. A nominal review that never changes outcomes does not establish genuine intervention. Where the score determines the result, the lender needs a lawful Article 22 route before the first affected application. These controls are recommended evidence of the actual decision process. (Regulation (EU) 2016/679, Arts. 5(2), 22, 24; Regulation (EU) 2024/1689, Art. 14(4).)
Applicants covered by GDPR Article 15(1)(h) need an intelligible explanation, not a model label or a generic statement that algorithms were used. In Dun & Bradstreet Austria, the Court required accessible information about the procedure and principles actually applied to the person's data. Trade-secret claims require an appropriate balancing process; they do not justify an automatic refusal to disclose relevant information. The supply contract must give the lender sufficient information to answer access requests and challenges. (Dun & Bradstreet Austria, Case C-203/22, EU:C:2025:117, operative part; Regulation (EU) 2016/679, Arts. 12, 15(1)(h).)
Prepare a data protection impact assessment before the personal-data phase where Article 35 applies. Systematic and extensive credit profiling supporting consequential decisions engages Article 35(3)(a); the general high-risk test can apply before that scale is reached. The assessment should cover rejected applicants, inaccurate inputs, exclusion risks, support access and the possibility of mechanical reliance. Residual high risk requiring Article 36 consultation must be addressed before processing starts. (Regulation (EU) 2016/679, Arts. 35–36.)
Article 86 applies to specified Annex III-based decisions with legal or similarly significant effects. Affected persons must consider the decision adverse to their health, safety or fundamental rights. It gives them a right to explanations about the system's role and the main elements of the decision. Statutory exceptions and limits apply where Union law already provides the right. The deployment file must assess that provision separately from Article 22, including the applicable Article 111 transition. (Regulation (EU) 2024/1689, Arts. 86, 111, 113.)
Sensitive information, fairness and consumer-credit restrictions
Financial behaviour can reveal sensitive facts even when the input schema avoids explicit labels. A transaction description may disclose medical treatment or religious activity. Article 9 applies to personal data revealing its listed categories, and ordinary Article 6 grounds cannot replace an Article 9 condition. The proposed score should exclude those fields and test whether engineered features reproduce the same information. Fairness also requires examination of harmful errors and unjustified exclusion across the intended applicant population. (Regulation (EU) 2016/679, Arts. 5(1)(a), 9, 25.)
Bias auditing does not grant permission to reuse sensitive attributes as credit features. Amended AI Act Article 4a permits narrowly conditioned processing for bias detection and correction. Its safeguards include strict necessity, inability to achieve the purpose effectively with other data, controlled access and deletion. It also prohibits transmission, transfer or access by other parties to the special-category data covered by that permission. The parties should keep any qualifying audit dataset separate from score inputs and assess each recipient's legal position. (Regulation (EU) 2024/1689, Art. 4a(1)–(2), as inserted by Regulation (EU) 2026/1744.)
Consumer-credit requirements have their own timetable. Directive (EU) 2023/2225 requires Member States to apply their implementing measures from 20 November 2026. Article 18(3) excludes GDPR special-category data from the creditworthiness information and excludes social networks as an external source. Article 18(8) provides intervention and explanation rights where automated processing is used, without reproducing GDPR's solely-automated threshold. The country-specific release must address the applicable implementing law; waiting for December 2027 would miss this earlier consumer-credit date. (Directive (EU) 2023/2225, Arts. 18(3), 18(8), 48(1).)
Kenyan training, commercial use and rights
The Kenyan company must establish the lawful origin and permitted uses of its training records. Kenyan establishment and processing engage the Data Protection Act's territorial provisions. The provenance file should identify the collector, original purpose, source contracts, notices, consent records where relied upon, subsequent disclosures and retention rules. Public availability or purchase from a broker does not answer those questions. (Data Protection Act 2019 (Kenya), ss. 4, 25, 28–30, 39.)
Commercial training also requires scrutiny under section 37. That section requires express consent or authorisation under written law accompanied by the prescribed collection information for commercial use. General Regulation 14 defines commercial purposes broadly, including advancing economic interests and effecting transactions. For a model developed for sale, a section 30 legitimate-interests analysis alone cannot establish compliance with the additional commercial-use condition. The source review must establish the applicable section 37 route before continued personal-data training. (Data Protection Act 2019 (Kenya), ss. 30, 32, 37; Data Protection (General) Regulations 2021, reg. 14.)
Where high-risk processing triggers section 31, the company must undertake a DPIA before processing. Section 31(5) requires submission of the report sixty days before processing, and section 31(3) addresses consultation with the Commissioner. This timing belongs in the training and data-access schedule. It cannot be replaced by the bank's EU DPIA or a general warranty that the vendor follows Kenyan law. (Data Protection Act 2019 (Kenya), s. 31.)
ODPC registration must match the company's controller and processor activities. The Registration Regulations require registration for the Third Schedule purposes, including provision of financial services. A small-business exemption cannot be assumed for credit-scoring processing merely from the company's headcount or turnover. Registration establishes the specified data-handler status; it does not certify a model's accuracy or authorise EU lending. A policy or strategy cannot substitute for the permissions and lawful bases required by the applicable statutes. (Data Protection Act 2019 (Kenya), ss. 18–20; Data Protection (Registration of Data Controllers and Data Processors) Regulations 2021, reg. 13, Third Schedule, item 8.)
The company must maintain a practical process for access, correction, objection, erasure and restriction requests. Section 35 separately protects people against specified solely automated consequential decisions, with exceptions and reconsideration rights. Training-only activity and consequential scoring require separate application of that provision. Source-data corrections should trigger an assessment of affected datasets, outputs and model versions. The contract should allocate investigation, response and remediation duties between the parties. (Data Protection Act 2019 (Kenya), ss. 26, 34–36, 38, 40; Data Protection (General) Regulations 2021, regs. 7–13, 24–25.)
An unlawful training operation requires a remediation decision; a contractual warranty cannot cure it. Depending on the defect, that decision may require deleting records, obtaining a lawful source or retraining. The EDPB's nonbinding AI-model opinion treats anonymity and the consequences of unlawful training as fact-specific questions. Neither universal model contamination nor automatic cleansing through anonymisation is a sound assumption. Licentium's Kenya AI regulation overview provides the broader country context. (Data Protection Act 2019 (Kenya), ss. 25, 37, 40; EDPB, Opinion 28/2024, sections 3.2, 3.4.)
Transfers and support access involving Kenya
An EU-to-Kenya disclosure needs a GDPR Chapter V route in addition to a lawful processing basis. Kenya does not appear on the Commission's adequacy list. The parties must therefore identify an applicable Article 46 safeguard, or a genuinely applicable derogation, before a transfer. The instrument must fit the parties' actual roles and territorial position. Routine support or ongoing scoring should not be designed around exceptional Article 49 derogations. (Regulation (EU) 2016/679, Arts. 44–46, 49; European Commission, Adequacy decisions.)
Remote access by a separate Kenyan service provider can constitute a transfer even when the database remains in Europe. The EDPB's transfer guidance distinguishes disclosure to a separate recipient from access by an employee forming part of the same controller. That distinction does not remove the need to secure overseas access. The proposed contract blocks Kenyan personal-data access until the lender approves a separate transfer assessment, suitable contractual safeguards and effective technical protections. (EDPB, Guidelines 05/2021, version 2.0, sections 2–3; Regulation (EU) 2016/679, Arts. 32, 44–46.)
A Kenya-hosted service adds a second direction of analysis. Export of Kenyan training records and onward disclosure of personal data from Kenya engage Kenyan law. Section 48 and General Regulations 40–48 regulate transfers outside Kenya. An exporter relying on section 48(a) or (b) must give the Commissioner proof of the prescribed safeguards. Transfers based on appropriate safeguards must also be documented under General Regulation 41(2), with the records supplied to the Commissioner on request. For sensitive personal data, section 49(1) requires consent and confirmation of appropriate safeguards. Kenya's sensitive-data definition also includes property details and family information that need not fall within GDPR Article 9. The parties need separate EU and Kenyan data classifications. (Data Protection Act 2019 (Kenya), ss. 2, 48–49; Data Protection (General) Regulations 2021, regs. 40–48.)
Kenyan localisation is not a blanket rule for all credit information. General Regulation 26 identifies specified strategic-interest processing and permits processing in Kenya or at least one serving copy there. Its categories include protected computer systems and specified education and health processing. The company must classify source datasets and systems before export. An EU destination does not itself satisfy the Kenyan export test, just as Kenyan compliance does not satisfy the EU transfer test. (Data Protection Act 2019 (Kenya), s. 50; Data Protection (General) Regulations 2021, reg. 26.)
Bank ICT procurement and outsourcing assessment
For the proposed bank buyer, a maintained scoring API, hosted service or supported software installation should be assessed as an ICT service. DORA covers ongoing digital and data services within Article 3(21), and credit institutions fall within Article 2. Its application began on 17 January 2025. A standalone report purchase can present a different service profile; contractual substance determines the assessment. A small evaluation contract is not automatically outside DORA. (Regulation (EU) 2022/2554, Arts. 2(1)(a), 3(21), 4, 64.)
The bank must distinguish an ICT service, a service supporting a critical or important function, and a provider designated critical under Article 31. Those categories trigger different consequences. A credit-decision dependency may support a critical-or-important-function assessment, but the parties must assess the actual disruption and compliance consequences. The Kenyan vendor does not become a designated critical third-party provider merely by selling to a bank. (Regulation (EU) 2022/2554, Arts. 3(22), 28–31.)
Article 28 requires the bank to assess arrangements before contracting, maintain its information register and retain responsibility. The bank must also inform its competent authority in a timely manner about planned ICT arrangements supporting critical or important functions and when a supported function becomes critical or important. Article 30 requires written service descriptions, locations, data protection, recovery and return, incident assistance, supervisory cooperation and termination provisions. Contracts supporting critical or important functions need the additional Article 30(3) protections, including measurable service levels, audit access and exit arrangements. The procurement schedule should identify subcontractors and changes to service or processing locations. (Regulation (EU) 2022/2554, Arts. 28(1)–(4), 29, 30(1)–(3).)
The outsourcing assessment should separately describe the function being entrusted to the supplier. Purchasing external information, operating the bank's recurring scoring process and performing an underwriting activity are different arrangements. Retention of the final lending decision does not eliminate an outsourced operational dependency. The proposed release requires the bank to resolve its applicable outsourcing and supervisory requirements alongside DORA. A non-bank lender needs its own regulatory-perimeter assessment; lending alone does not establish DORA coverage. (Regulation (EU) 2022/2554, Arts. 2, 28–30.)
Historical evaluation and live testing
Begin with an evaluation agreement that prohibits operational reliance. Synthetic records created without personal inputs are the simplest test material. De-identified historical records require an identification-risk assessment; pseudonymised records remain personal data for the bank where it retains the means to re-identify applicants. Creating anonymous or synthetic records from personal data is itself processing that needs justification. Tests should examine leakage from outputs and model weights before treating either as anonymous. (Regulation (EU) 2016/679, recital 26, Arts. 4(1), 4(5), 5–6; EDPB, Opinion 28/2024, section 3.2.)
A historical-data pilot should use completed applications and keep scores away from credit files, collections, repricing and future lending decisions. Restrict access to the validation team and delete row-level material under a stated schedule. A pre-market research or development activity can fall within Article 2(8), but real-world testing is expressly outside that exclusion. The bank and vendor should record which activity they are conducting before exposing a current applicant to the system. (Regulation (EU) 2024/1689, Art. 2(8); Regulation (EU) 2016/679, Arts. 5, 25, 32.)
Synthetic evaluation can test integration, permissions, explanation formats and failure handling. It cannot, by itself, establish repayment prediction or fairness for the bank's population. The validation protocol should examine out-of-time performance, calibration, ranking, subgroup error rates and missing-data effects. It should compare the score with the bank's existing process and record uncertainty. Historical outcomes limited to approved borrowers require an explicit assessment of selection bias. No numerical acceptance threshold should be represented as achieved before the bank's independent validation team measures it. (Regulation (EU) 2024/1689, Arts. 9–10, 15; Regulation (EU) 2016/679, Arts. 5(1)(a), (d), 24.)
A controlled live shadow pilot processes current applications while hiding scores from decision-makers. It therefore still needs lawful personal-data processing, notices, security and any required DPIA. If conducted as pre-market testing in real-world conditions, the parties must use an applicable lawful testing route. Outside a sandbox, Article 60 requires an approved testing plan, registration and EU establishment or an EU-established legal representative. Tacit approval after thirty days applies only where national law permits it. Testing may last no more than six months, with a further six-month extension subject to the specified notification and explanation. The provider and participating deployer must agree their responsibilities. Article 61 governs informed participation. A bank's internal innovation approval does not replace those requirements. (Regulation (EU) 2024/1689, Arts. 60–61; Regulation (EU) 2016/679, Arts. 6, 13–14, 35.)
Article 60 is not permission to let an unfinished score cause irreversible lending harm. Its conditions include the ability to reverse and disregard predictions, safe withdrawal and additional controls for vulnerable participants. Research consent also does not replace GDPR's separate rules or confer general permission for later commercial training. The recommended live test keeps ordinary loan decisions independent of the experimental output. Once staff can rely on the score, the parties should treat the phase as operational deployment for their contractual release controls. (Regulation (EU) 2024/1689, Arts. 60(4)(g), (i)–(k), 60(5), 61; Regulation (EU) 2016/679, Arts. 6, 22.)
Evidence required for the production version
Build the provider file during evaluation rather than after a successful benchmark. It should connect the intended purpose to risk controls, training provenance, validation results and known limitations. Under the applicable high-risk regime, the provider must address technical documentation, logging, instructions, human oversight, accuracy, cybersecurity and quality management. The file should identify the exact feature transformations and model version delivered to the lender. General claims about accuracy cannot replace evidence for the intended population. (Regulation (EU) 2024/1689, Arts. 9–17, Annex IV, subject to Arts. 111 and 113.)
The provider's market-access package must include the conformity steps applicable to the release date and transition. Annex III credit systems normally follow internal control under Annex VI, without mandatory notified-body involvement under Article 43(2). Where required, the package includes the EU declaration, CE marking, registration and an EU-established authorised representative. These steps do not constitute bank approval or a lending licence. Substantial modifications require a fresh Article 43 assessment where that provision applies. (Regulation (EU) 2024/1689, Arts. 16, 22, 43(2), 43(4), 47–49, Annex VI, subject to Arts. 111 and 113.)
The provider also needs post-market monitoring and a serious-incident reporting procedure under the applicable regime. The contract should require the bank to supply relevant operational evidence without granting unrestricted training reuse. The release assessment must apply Articles 72–73 and their own timing, rather than treating all duties as deferred Chapter III requirements. (Regulation (EU) 2024/1689, Arts. 72–73, 111, 113; Regulation (EU) 2016/679, Arts. 5, 28.)
The bank needs its own deployment file. Article 26 requires use according to instructions, competent oversight, monitoring and the relevant input-data and logging controls. Creditworthiness deployers within Annex III, point 5(b), fall within Article 27's fundamental-rights impact assessment requirement when applicable. That requirement is not confined to public bodies. A GDPR DPIA can supply overlapping material but does not automatically discharge the separate assessment, notification and update duties. (Regulation (EU) 2024/1689, Arts. 26–27, subject to Arts. 111 and 113.)
Contractual validation should include an independent challenge to feature necessity, cohort coverage, calibration and adverse-outcome patterns. Test the explanation and complaint workflow with actual model outputs before release. Security testing should cover unauthorised score queries, data extraction, access escalation and failover. Establish stop conditions for data corruption, unsupported populations, drift and unexplained disparities. The bank should retain a workable lending process if the service is suspended. These are recommended acceptance controls that implement the identified data, oversight and continuity duties. (Regulation (EU) 2016/679, Arts. 24–25, 32; Regulation (EU) 2022/2554, Arts. 28(8), 30(3); Regulation (EU) 2024/1689, Arts. 9, 14–15.)
Contract stages and the deployment release
Use a master agreement with separately signed evaluation, live-test and production schedules. The first schedule should permit only the approved data and test activities. It should exclude automatic conversion, production reliance and independent reuse. Payment should attach to agreed deliverables and acceptance tests, without inventing a performance warranty that the company cannot substantiate. The bank should be able to terminate after evaluation without a production purchase commitment.
Before any personal record enters an evaluation, require a data-release approval. It should identify source rights, purposes, legal bases, retention, roles, recipients and security controls. Execute the Article 28 terms where the vendor is a processor and complete any required DPIA and consultation. Keep Kenyan personal-data access disabled unless the separate transfer conditions are satisfied. This data-release decision precedes the later decision to let the score influence lending. (Regulation (EU) 2016/679, Arts. 5–6, 28, 35–36, 44–46; Data Protection Act 2019 (Kenya), ss. 30–31, 37, 48–49.)
A live-test schedule should specify the permitted applicant cohort, start and end events, masking controls, participant safeguards and authority conditions. It should name who can stop the test and how records and outputs are removed. The provider must notify the bank of defects, incidents and proposed changes promptly enough for the bank to meet its own deadlines. Subcontracting and remote access should remain prohibited unless expressly authorised through the agreed controls. (Regulation (EU) 2024/1689, Arts. 60–61; Regulation (EU) 2016/679, Arts. 28(2)–(4), 33; Regulation (EU) 2022/2554, Art. 30.)
Under the recommended contract, the production gate is a signed release order before the first decision-maker receives an actionable score. The bank's authorised credit, privacy, legal, model-risk and ICT owners should record acceptance of the specified model and country. The release must establish lawful data use, independent local validation, effective human review or a lawful Article 22 exception, and functioning explanation and challenge procedures. It must also confirm the required assessments, applicable conformity position, outsourcing determination and DORA contract. A failed condition keeps the score masked or the service stopped. (Regulation (EU) 2016/679, Arts. 5(2), 22, 24, 35; Regulation (EU) 2022/2554, Arts. 28–30; Regulation (EU) 2024/1689, Arts. 26–27, 43, 111, 113.)
The production agreement should allocate remediation costs, audit assistance, data return, deletion, continuity and exit support. It should address training-data and intellectual-property rights without converting a warranty into proof. Liability limits must preserve mandatory rights and supervisory access; their enforceability requires the chosen governing law. Changes to features, country, population, hosting, support access or learning behaviour should reopen the relevant release conditions. The permitted next step is therefore a bounded evaluation with an evidence-building workstream; operational use starts only when the agreed release conditions are actually met. (Regulation (EU) 2016/679, Arts. 28(3), 32, 82; Regulation (EU) 2022/2554, Arts. 28(7)–(8), 30; Regulation (EU) 2024/1689, Arts. 25, 43(4).)