Why AI Should Not Be Regulated Broadly
A blanket rulebook for AI sounds prudent until you ask a basic compliance question: regulated how, exactly? The case for why AI should not be regulated starts there. AI is not a single product, business model, or risk class. It is a general-purpose capability used for sanctions screening, fraud detection, coding assistance, document review, customer service, and synthetic media generation. Treating all of that as one regulatory object is not precision. It is category error.
For regulated firms, that distinction matters. Banks, insurers, asset managers, fintechs, and market infrastructure providers already operate under dense obligations tied to outcomes: consumer protection, model risk, AML, sanctions, privacy, operational resilience, governance, and recordkeeping. The real policy question is not whether AI should sit outside scrutiny. It is whether new horizontal regulation aimed at the technology itself would improve accountability, or simply add another layer of ambiguity on top of existing rules.
Why AI should not be regulated as a single category
The strongest argument against broad AI regulation is that it confuses tools with conduct. Regulators do not usually ban or license spreadsheets because spreadsheets can be used to make bad decisions. They regulate lending, advice, trading, disclosure, surveillance, and financial promotions because those activities create identifiable risks and legal duties.
AI should be approached the same way. A chatbot helping a compliance team summarize supervisory findings does not create the same exposure as an underwriting model, a biometric surveillance system, or an autonomous targeting tool. If the law treats all of them as substantially similar because they share a technical label, firms inherit uncertainty without gaining clarity.
That uncertainty is not theoretical. It affects procurement, model governance, cross-border deployment, documentation standards, and internal approval workflows. Compliance teams end up spending time interpreting vague AI definitions instead of testing for concrete harms such as discrimination, error rates, explainability gaps, data leakage, or weak controls over human review.
The better target is harmful use, not the technology itself
A disciplined regulatory framework starts with risk events and regulated outcomes. In financial services, that means asking whether an AI system affects customer treatment, market integrity, sanctions compliance, financial crime controls, capital decisions, or regulatory reporting. If it does, then the existing perimeter often already supplies the right questions.
A model used in transaction monitoring should be tested for effectiveness, tuning discipline, escalation quality, and governance. A system used in customer onboarding should be examined for fairness, documentation, and control design. An internal productivity assistant that drafts policy language may require security controls, access restrictions, and validation, but not the same intensity of supervisory treatment as a customer-facing decision engine.
This is why AI should not be regulated in broad, technology-first terms. Harm comes from context, data, incentives, and deployment. Two models built on similar architecture can present radically different legal and operational risk depending on what they do, who relies on them, and how much human challenge is built around them.
Overbroad rules can reduce accountability
Counterintuitively, sweeping AI laws can make governance worse. Once a tool is labeled “AI compliant,” management may treat that label as a substitute for judgment. The organization focuses on satisfying generic checklists rather than interrogating the specific control failures that drive enforcement.
That is a familiar pattern in compliance. Formal adherence to process is not the same as effective risk management. A policy can exist on paper while controls fail in practice. The same applies here. An AI inventory, a registration requirement, or a standard impact assessment may be useful, but only if tied to real decision risk. Otherwise, firms generate documentation volume, not defensibility.
Existing regulation already reaches much of the problem
One reason the debate becomes overstated is that many stakeholders speak as if AI operates in a legal vacuum. In regulated sectors, it does not. If an AI model generates unfair lending outcomes, existing fair lending and anti-discrimination rules are implicated. If it mishandles personal data, privacy law applies. If it creates misleading disclosures or defective advice, conduct rules and liability frameworks are already available. If it weakens sanctions controls or AML surveillance, the enforcement path is obvious.
That does not mean the current framework is perfect. It means policymakers should identify genuine gaps instead of regulating “AI” as a catch-all. In some areas, targeted updates are justified. Firms may need clearer expectations on validation for large language models, vendor concentration risk, provenance controls, or governance over human override. Those are credible interventions because they attach to defined risks.
By contrast, broad legal definitions of AI can become obsolete quickly. They either sweep in ordinary analytics and rules-based software, or they become so technical that firms spend months arguing scope. Neither outcome helps a chief compliance officer trying to assess exposure across jurisdictions.
Innovation is not a slogan in compliance – it affects control quality
There is also a practical reason why AI should not be regulated too broadly: restrictive rules can slow the adoption of systems that improve compliance outcomes. In financial services, manual processes are not neutral. They are expensive, inconsistent, hard to audit, and often too slow for the pace of regulatory change.
A well-governed AI system can reduce those weaknesses. It can surface regulatory changes across jurisdictions faster than manual research, identify policy gaps more consistently, and improve alert triage by highlighting relevant factors. It can help legal and compliance teams spend less time collecting information and more time applying judgment.
If regulation makes low-risk internal use unnecessarily difficult, institutions may keep relying on fragmented spreadsheets, inbox-driven workflows, and outsourced manual review. That preserves the very operational fragility regulators usually want firms to reduce.
For supervisory authorities, there is a wider policy concern. Overregulation tends to favor large incumbents that can absorb compliance overhead. Smaller firms, specialist vendors, and internal innovation teams often cannot. The result is not safer markets by default. It can mean less competition, weaker tooling diversity, and slower improvement in controls.
Where restraint ends: sectors and uses that do need hard rules
None of this is an argument for laissez-faire deployment. Some AI use cases plainly warrant stringent requirements or outright prohibition. Systems that materially affect rights, safety, access to essential services, or coercive state power deserve a high bar. So do models used in high-impact financial decisions where bias, opacity, or data quality failures can cause measurable harm.
In those settings, firms should expect rigorous standards around testing, monitoring, recordkeeping, accountability, incident response, and independent review. Vendor claims should never substitute for internal assurance. Human oversight should be real, not ceremonial. And boards should understand where AI changes the firm’s risk profile rather than treating it as another software procurement.
That is the disciplined middle path: regulate high-risk uses aggressively, supervise outcomes continuously, and avoid turning a broad enabling technology into a legal category so wide that it loses meaning.
What a smarter policy approach looks like
A workable framework would do four things. First, it would classify use cases by impact, not by whether a tool meets an abstract AI definition. Second, it would align requirements with existing sector rules instead of creating duplicate obligations. Third, it would focus on evidence of control effectiveness – testing, traceability, escalation, and governance – rather than headline promises about “responsible AI.” Fourth, it would preserve room for lower-risk internal applications that improve operational resilience and compliance capacity.
That approach is especially important in cross-border environments, where firms already face fragmented supervisory expectations. What compliance teams need is not another vague layer of principle. They need clear, defensible answers on what controls are required for a specific use, in a specific jurisdiction, with a specific risk profile.
That is also where specialized regulatory intelligence matters more than generic policy debate. The question is rarely whether AI is good or bad. It is whether a particular deployment changes legal obligations, supervisory scrutiny, or enforcement exposure in ways the institution can document and defend.
The serious case against broad AI regulation is not ideological. It is operational. Regulate conduct. Regulate outcomes. Regulate high-risk deployments with precision. But do not regulate all AI as if the label itself tells you enough. In compliance, bad categories create bad controls, and bad controls are what regulators punish.
