AI regulation focuses on the technology itself, while regulating the use of AI in financial services focuses on how firms apply that technology and what effects it has on customers and markets. The FCA has said its role is the second one. That distinction matters because it shifts attention to governance, controls, accountability, and outcomes.
AI regulation and AI use in financial services address different control problems
ai regulation is usually technology-centric. It asks what rules should govern the design, deployment, and sale of AI systems themselves. Regulating the use of AI in financial services is sector-centric. It asks how a regulated firm uses AI inside lending, trading, advice, fraud, onboarding, operations, and customer service, and whether those uses remain fair, accountable, safe, and resilient.
That difference matters because the sector lens shifts the practical test from abstract model compliance to business outcomes, control ownership, and supervisory accountability. A financial firm may use a system that is lawful as a technology product but still fail if its deployment creates poor customer treatment, weak model governance, or unacceptable conduct risk. The right lens depends on whether you are regulating the AI system or the regulated activity.
For the technology lens, the policy question is often about baseline requirements for developers, providers, or deployers of AI systems, including documentation, transparency, testing, and restrictions on higher-risk use cases. For the financial-services lens, the question is whether the institution can explain the use, monitor it, challenge it, and evidence that it meets existing obligations around governance and customer outcomes. EU AI Act regulatory framework is a useful reference point for the first category, because it regulates AI systems as such rather than only the sector using them.
In practice, firms should expect different evidence demands depending on which lens applies. A technology rule may focus on model documentation, training data governance, testing, and post-market obligations. A financial-services rule usually focuses on approved use cases, human oversight, model risk management, auditability, change control, and the customer or market effects of the decisioning process. That is why the same AI tool can fall under both regimes, but for different reasons and with different supervisory questions.
Why the financial-services lens changes governance and accountability
When regulators focus on the use of AI in financial services, the central issue is not whether the model exists, but whether the firm can govern its use. That means clear ownership, approved boundaries, monitoring for drift or bias, and escalation paths when outputs affect customers, prices, access, or suitability. The key question is whether the firm can show that AI remains subordinate to its risk framework rather than replacing judgment with opaque automation.
This is why sector regulation often interacts with existing conduct, operational resilience, and third-party risk obligations. If an AI tool influences credit, fraud, complaints handling, claims, surveillance, or advisory workflows, the firm still needs controls around validation, override, logging, and accountability. A model can be technically sophisticated and still be poorly governed if no one can explain who approved it, how it is monitored, or what happens when it fails.
Financial-services supervision also tends to care about downstream effects, not just input correctness. A technically accurate system can still produce unfair or unstable outcomes if it is trained or tuned in ways that amplify exclusion, inconsistency, or market impact. That is where regulatory focus shifts from model design to operational consequences, including customer treatment, market integrity, and resilience of decision-making.
DORA, the Digital Operational Resilience Act is a useful comparator for this sectoral perspective because it shows how financial regulation often targets resilience, governance, and third-party dependence rather than just the underlying technology. For a broader controls view, NIST Cybersecurity Framework 2.0 maps well to the governance, protect, detect, respond, and recover expectations that financial firms often need around AI use.
What practitioners should watch for when both regimes overlap
Most real deployments sit in the overlap. The AI product may be subject to one set of rules, while the financial firm using it is responsible for another. That creates a practical burden: vendors want to satisfy product obligations, while firms need evidence that the system is safe in context, with their data, their customers, and their operating model. Contracts, assurance artefacts, and monitoring obligations therefore become part of the control design, not just procurement paperwork.
Practitioners should also watch for false comfort from “compliance by vendor.” If the provider says the AI is compliant, the firm still has to validate suitability, define permitted uses, and maintain control over outcomes. In regulated financial workflows, the user of the model often owns the business risk even when the technology stack is outsourced.
What to verify: Check whether your evidence package distinguishes model compliance from use-case compliance. You should be able to show who owns the decision, what the human override path is, how exceptions are handled, and which customer-impact metrics are monitored.
Decision rule: If the question is about the AI system itself, treat it as technology regulation; if the question is about lending, advice, surveillance, trading, onboarding, or servicing, treat it as regulated use in context and test the control environment around that use.
Practitioner takeaway: The safest operating model is to assume both lenses may apply, then prove that the firm can govern the use case, not just purchase the technology.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 set the technical controls, while EU AI Act and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | GPAI and high-risk AI obligations — High-risk and provider obligations | This question contrasts AI system regulation with sector use of AI. |
| Recommendation — Assess AI systems against provider and high-risk obligations when the technology itself is regulated. | ||
| DORA | ICT third-party risk management — Third-party and ICT risk management | Financial firms using AI depend on vendors, hosting, and operational controls. |
| Recommendation — Apply third-party and ICT controls to AI suppliers and outsourced model services. | ||
| NIST CSF 2.0 | GOV — Govern | The financial-services use case depends on governance, ownership, and accountability. |
| PR — Protect | AI use in finance needs preventive controls over access, change, and configuration. | |
| DE — Detect | Financial AI deployments need monitoring for drift, errors, and adverse outcomes. | |
| Recommendation — Assign accountable ownership and oversight for AI use cases under governance controls. Implement protective controls around approved AI use, change control, and access restrictions. Monitor AI outputs and model behaviour for drift, anomalies, and harmful outcomes. | ||
Related resources from NHI Mgmt Group
- What is the difference between sanctioned AI use and shadow AI in SaaS?
- What is the difference between shadow AI and approved AI use?
- What is the difference between governing AI model development and governing shadow AI use?
- What is the difference between blocking AI use and redacting sensitive data before a prompt is sent?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
