Enhancing RAID and MART for AI adoption

To modernise RAID (Risks, Assumptions, Issues, Dependencies) or MART (Mitigation, Accountability, Reporting, Transparency) assessments for AI, you must move them from fixed, point-in-time spreadsheets into dynamic frameworks. They belong in a wider AI governance framework that is closely aligned to your data governance strategy. MEGA.AI embraces this approach to operationalising compliance and service delivery at scale.

A regulatory landscape that has shifted

The regulatory landscape has shifted completely in 2026. The Data (Use and Access) Act (DUAA) has materialised, the FCA's Mills Review expects “agentic finance” oversight, and the ICO's code of practice enforces strict accountability. Overlay this with Ofcom's requirements. Regulators are explicitly moving from assessing static models to supervising real-time system behaviour. The consultation on the ICO's corporate strategy closes on 23 August 2026, with AI and cyber resilience two of its four areas of strategic focus.

Debt resolution deals with financially distressed individuals and with non-financial vulnerabilities, so the Joint FCA and ICO Statement on vulnerability data (March 2026) and the FCA Consumer Duty rule to “avoid foreseeable harm” apply heavily. RAID and MART frameworks need to be adapted for these specific operational profiles.

Deploying deterministic AI bots for debt resolution or debt advice creates a unique regulatory intersection. Deterministic bots (for example rigid decision-tree bots, pattern-matching workflows or non-generative classification models) avoid the “hallucination” issues of generative AI. The risks of systemic bias, errors at scale and algorithmic harm still need to be carefully mitigated.

We are seeing the evolution of sector-specific LLMs, in some instances funded by MaPS to adhere to its new FCA-approved standards (bedding in between April and October 2026). Similarly, the HM Treasury Fairness Group has been looking at a community across central government debt management functions (for example at HMRC, DVLA and DWP).

Understanding your use case and priorities

Start with what the deployment has to achieve, then with the questions any vendor must be able to answer before a bot speaks to a customer.

Enhancing RAID for AI adoption and deployment

The standard RAID log fails when applied to AI because machine learning risks are systemic, non-linear and continuously evolving. We need to plan for continuous improvement and AI learning.

Risks: from operational friction to algorithmic and systemic vulnerabilities

• Data poisoning and feedback loops: Log the risk of generative or agentic outputs re-entering the model as training data, degrading accuracy over time (model collapse).
• Algorithmic discrimination: Explicitly map risks where AI-driven automated decision-making (ADM) unintentionally creates unfair outcomes or financial exclusion for people with protected characteristics.
• Shadow AI proliferation: Track the risk of employees feeding proprietary corporate or client data into unapproved third-party LLMs.

Assumptions: from project delivery metrics to model behaviour parameters

• Explainability: Do not assume third-party vendor tools have inherent or built-in compliance. Log exactly how the model arrives at output decisions to maintain audit trails.
• Data lineage consistency: Document assumptions that source data remains structured, clean and safe from drift after deployment.
• Human-in-the-loop effectiveness: Formally test the assumption that staff can effectively challenge or override AI suggestions.

Issues: from simple system downtime to dynamic model failures

• Model drift: Track performance decay where real-world data shifts away from the initial training data profile.
• Hallucinations and false guidance: Capture occurrences where bots give factually incorrect or harmful financial guidance.
• Unintended autonomous agent escalation: Flag instances where an autonomous agent operates outside its predefined sandbox perimeter.

Dependencies: from project timelines to complex supply chain ecosystems

• Critical third party (CTP) over-reliance: Map dependencies on foundational infrastructure providers (for example AWS, Azure and OpenAI) to align with HM Treasury and FCA infrastructure rules.
• Data controller versus processor and sub-processor dynamics: Clearly detail dependencies on external data scrapers or vendors, setting out exactly where legal liability sits if a data breach occurs.

AI-specific RAID enhancements for debt resolution bots

Risks: downstream API failure and data blending

• API misclassification of vulnerability data: A third-party API categorises a vulnerable customer incorrectly (for example by missing a mental health indicator), causing the bot to apply standard, more assertive collection scripts automatically.
• Affordability cascades: The bot pulls incorrect or lagging affordability data from an API, creating a repayment plan that forces the customer into further hardship, in breach of the FCA Consumer Duty and CONC 7.
• Data aggregation overlap: Mixing in-house CRM histories with external API streams creates an accidental profile that infers health status, inadvertently creating special category data without a valid lawful basis under ICO guidance.

Assumptions: stress-test your system integration parameters

• Real-time vendor service level agreements (SLAs): Assuming third-party vendor APIs will always respond fast enough, with minimal latency, to feed the bot during a live, multi-channel customer interaction.
• Static vulnerability thresholds: Assuming that a consumer's financial vulnerability status is fixed, rather than a dynamic state that can change from week to week.
• Equivalence of data processing: Assuming vendor APIs handle, store and mask data with the same strict regulatory controls your in-house models use.

Issues: automated compliance velocity

• Systemic hard-coding faults: If a rule in your deterministic engine contains a logic error, the bot will scale that non-compliant action across thousands of customers in minutes.
• API timeout deadlocks: The vulnerability API drops or times out mid-session, causing the bot to default to an aggressive “non-vulnerable” recovery path.
• Frictionless non-compliance: The bot automatically registers a payment agreement that exceeds the customer's actual disposable income because the CRM data was not updated in time.

Dependencies: map legal boundary vulnerabilities

• Joint controller liability: Relying on external affordability and vulnerability vendor APIs can pull you into a shared-liability position under the ICO's data controller guidance if that vendor improperly scraped or processed consumer data.
• Data synchronisation gaps: The exact delay (latency) between a customer reporting a vulnerability to a live human agent and that indicator updating across the bot's CRM data feed.

Scraping is very unusual in the UK market. It is more prevalent where services such as open banking are less mature.

Enhancing MART for AI governance and safeguarding

A MART matrix must be redesigned to focus heavily on safety, systemic resilience and strict regulatory consumer protection.

Mitigation: from patching bugs to automated, guard-railed system protection

• Real-time guardrails: Implement automated monitoring overlays that scan, filter and block harmful or non-compliant model outputs before they reach a consumer.
• Synthetic data red-teaming: Use the FCA's Supercharged Sandbox or similar synthetic environments to stress-test models rigorously against severe market shock scenarios. This includes the FCA's Scale-up Unit.

The FCA has focused on fast-growing fintechs with a range of support tools and examples of good and poor practice.

Accountability: upgrade to personal regulatory liability

• SM&CR personal liability: Under the Senior Managers and Certification Regime, assign a specific SMF holder (for example SMF16) to sign off AI risks. Regulators have been clear that “the algorithm did it” is not a defence.
• AI risk registers: Establish a central corporate repository (for example SharePoint) detailing every AI tool in use, its core purpose and its SMF owner.

Reporting: from monthly status reports to near-miss registers and continuous telemetry

• AI near-miss sharing: Align with the financial sector's drive toward anonymous repositories for sharing AI failures and operational near misses.
• Automated data feeds: Prepare your system architecture to feed automated telemetry directly into the FCA's agentic supervisory frameworks.

Transparency: from obscure privacy notices to actionable consumer disclosures

• Consumer Duty compliance: Under the FCA Consumer Duty, you must clearly signal to customers when they are interacting with an AI, and prove the AI is actively delivering good outcomes.
• Contestability mechanisms: Give consumers clear, easy routes to dispute an AI decision and demand a rapid human review.

AI-specific MART enhancements for debt recovery bots

Mitigation: from reactive code fixes to systemic structural guardrails

• The mandatory “human escape hatch”: Embed a strict logic rule that cannot be blocked. For example, any customer mention of suicide, severe illness or extreme mental distress triggers an immediate handoff to a specialist human support team.
• API fallback fail-safes: Implement a strict fail-safe state. If any third-party vulnerability or affordability API fails to respond within milliseconds, the bot must default to the most lenient, non-aggressive collection pathway.

Accountability: bind systemic bot steps to designated human roles

• SMF16 and SMF17 sign-off: The relevant SMF holder (compliance oversight or money laundering reporting) must formally own and sign off the bot's rule-base architecture.
• Joint FCA and ICO data audit trails: For every automated debt arrangement, keep a permanent, unalterable audit trail showing exactly which vendor API data point was used to calculate the repayment term.

Reporting: track customer outcomes instead of interaction volume

• Consumer Duty outcome telemetry: Replace standard bot metrics (such as “conversations closed”) with customer outcome metrics (such as “percentage of bot-made agreements broken within 30 days”) to prove your tools are not causing foreseeable harm.
• API deviation alerts: Build automated dashboard reports tracking how often external vendor data conflicts with your internal CRM records.

Transparency: make sure consumers understand the automated process

• Explicit front-end disclosures: A clear, plain-language notice at the start of any conversation confirming that the customer is interacting with an automated bot, in line with UK GDPR and DUAA principles.
• Post-decision challenge paths: Clear, accessible steps that let a customer say “I do not agree with this automated affordability calculation”, automatically triggering an independent manual review of the API data used.

Regulatory matrix for debt recovery bots

DUAA and UK GDPR

Expectation: A strict right to human intervention for high-impact automated decision-making (ADM) involving special category data.

In practice: Your bot cannot finalise legally binding debt attachment or settlement terms without offering a prominent, one-step option to request a human agent.

FCA Consumer Duty (CONC 7 focus)

Expectation: Proactive proof that contact strategies do not cause financial distress, intimidation or harm to vulnerable customers.

In practice: Move from sampling 3 to 5% of bot interactions to automated post-call analytics that audit 100% of bot transcripts for compliance indicators.

ICO data protection and vulnerability data

Expectation: Inferring health, disability or mental state from blended CRM and API data creates special category data, which needs an Article 9 condition such as explicit consent.

In practice: Your in-house classifiers must not log persistent labels such as “likely depressed” based on third-party tracking behaviour unless an ICO-approved data-tagging protocol is followed.

Aligning with the regulators' direction of travel

Data (Use and Access) Act (DUAA)

Direction of travel: Loosens some restrictions on automated decision-making but enforces strict safeguards for high-risk profiling.

Impact on MART (mitigation and transparency): Make sure your automated systems have visible, built-in processes that allow consumers to challenge automated credit or fraud decisions.

FCA (Mills Review and agentic finance)

Direction of travel: Expects a shift to agent-led consumer journeys by 2030, and recommends an agentic supervisory model that gives the FCA AI-enabled tools to monitor firms.

Impact on RAID (issues and dependencies): Move away from quarterly spreadsheets. Build continuous automated tracing to prove your AI agents are under full administrative control.

ICO (data protection and auditing)

Direction of travel: Expects specialised data protection impact assessments (DPIAs) covering algorithmic bias, model drift and systemic privacy leaks.

Impact on MART (accountability): Make sure your Data Protection Officer (DPO) has full technical veto power over AI training sets and model deployments.

Practical implementation steps

1. Mandate pre-deployment DPIAs: No AI model goes live until a comprehensive, AI-focused DPIA is logged.
2. Audit the AI supply chain: Vet foundational models rigorously. Demand transparent data provenance from vendors to prevent copyright or data privacy failures.
3. Ditch sample-based monitoring: Move away from reviewing a small percentage of AI interactions. Implement automated analytics to verify that 100% of AI outputs meet the FCA's Consumer Duty threshold.

Supplier due diligence checklist

This checklist focuses on data provenance, systemic resilience and outcome alignment. It helps make sure your third-party vulnerability, affordability and CRM API suppliers do not compromise your compliance under Ofcom rules, the DUAA, the FCA Consumer Duty and ICO requirements.

1. Data provenance, lawful basis and compliance (ICO and DUAA)

When vendors provide vulnerability or affordability data, they are often processing sensitive information. Verify their legal right to collect and share it.

• Special category data mapping: Does the vendor provide indicators that infer health, mental health or disability? If so, have they documented a specific Article 9 condition under UK GDPR and the DUAA (for example substantial public interest)?
• Consent and sourcing transparency: How does the vendor source its data? If it uses web scraping, public registries or credit file profiling, can it provide an immutable audit trail showing customer notification or consent?
• Joint versus independent controllership: Does the vendor contractually define itself as an independent data controller, a joint controller or a data processor? If joint, your RAID log must capture the shared regulatory liability.
• Data minimisation and masking: Does the API let you pull only the specific score or flag you need, or does it force the transmission of unnecessary raw personally identifiable information (PII)?
• Right to erasure sync: How does the vendor handle a consumer's right to erasure? If a consumer asks the vendor to delete their data, how is that deletion signalled back to your in-house CRM and bot cache?

2. Algorithmic fairness, bias and accuracy (FCA Consumer Duty)

A deterministic bot is only as fair as the data feeding its logic engine. If a vendor API delivers flawed or biased data, your bot will scale that unfairness immediately.

• Data recency and latency SLAs: How often is the vendor's affordability and vulnerability data updated: in real time, every 24 hours or monthly? Lagging data risks forcing a customer into an unaffordable payment plan.
• Bias and discrimination auditing: Can the vendor provide its latest independent bias audit report? Do its scoring models show higher rates of false positives or negatives for protected characteristics or vulnerable groups?
• Model drift management: For vendors using machine learning to generate vulnerability scores, how often do they retrain the underlying models, and what are their alert thresholds for data drift?
• Ground truth verification: How does the vendor validate the accuracy of its indicators? What is its documented error margin for classifying a non-vulnerable consumer as vulnerable, or the reverse?

3. Technical integration and operational resilience (FCA rules)

Operational resilience rules mean you must treat critical APIs as extensions of your own infrastructure.

• API timeout and fail-safe architecture: What API response time (latency) does the vendor guarantee under peak load? Does it support a structured fail-safe payload if the system times out mid-interaction?
• Disaster recovery and redundancy: Is the vendor classified as a Critical Third Party (CTP) under the operational resilience framework? What is its documented Recovery Time Objective (RTO) for a total system outage?
• Rate limiting and throttling caps: Are there strict API call volume limits that could throttle your bot during high-volume periods, such as end-of-month collection cycles?
• Immutable audit trails: Does the API log every transaction with a unique, tamper-proof ID? Can that ID be passed into your internal CRM to prove to the FCA exactly what data the bot used to make a specific decision?

4. Contestability and redress

Under the FCA Consumer Duty and the DUAA, consumers must be able to challenge automated decisions easily.

• Data dispute SLAs: If a customer disputes an affordability score pulled from the vendor API, what is the vendor's formal turnaround time to investigate and correct the record?
• Explainability payload: Does the API response include clear reason codes explaining why a customer was flagged as vulnerable or as having low affordability? Your bot needs these codes to explain decisions to the customer or to a human agent.
• Regulatory indemnification: Does the vendor's contract include indemnities that protect your firm if the vendor's data is found to be unlawful, inaccurate or in breach of the ICO's code of practice?

The outcome that matters

When delivered correctly, scaled AI delivery should have a positive impact on consumer outcomes that can be evidenced.

Kevin Still is a non-executive director of MEGA.AI Limited.

Book a briefing to map RAID and MART controls to one of your own voice journeys.

Sources

• FCA, The Mills Review: AI and the future of retail financial services (July 2026)
• Joint FCA and ICO statement on regulatory expectations regarding firms' approaches to vulnerability related data (March 2026)
• ICO, Consultation on the corporate strategy (2026)
• Ofcom, AI chatbots and online regulation: what you need to know
• FCA, FCA sets out next phase of smarter, more effective regulation
• FCA, Scale-up Unit
• FCA, FCA boosts support for innovative firms as they scale and grow (August 2026)
• FCA, High-growth firms: good and poor practice (August 2026)