Sectoral AI Regulation and RegTech: SR 11-7, NYDFS 500, and Automating Regulatory Work

There is no single US AI regulator. If you deploy AI in a bank, a hospital system, or a utility, the rules that bind you already exist — they are sector rules, written for models, devices, and information systems generally, and your AI systems fall inside their definitions. The compliance question is mapping, not waiting.

That mapping has two halves. First, know which sectoral regime each AI use case lands in: the Federal Reserve's model risk guidance for banking models, FDA's device pathways for clinical AI, HIPAA's Security Rule for health data pipelines, the SEC and FTC for conduct and claims. Second, treat the regulatory workload itself — tracking rule changes, producing filings, assembling examination evidence — as an automation target. This guide covers both halves: the sectoral map, and the RegTech layer that makes living under it affordable. For the cross-border picture (the EU AI Act's horizontal approach is the philosophical opposite of the US sectoral one), see /guides/global-ai-regulation-guide; for voluntary frameworks that knit the sectors together, see /guides/ai-governance-standards-guide.

1. By the numbers

2. The tension: horizontal AI platforms meet vertical rules

Enterprise AI stacks are built horizontally — one model gateway, one RAG platform, one agent framework serving every business line. US regulation is vertical: the same underwriting copilot is a "model" to the Federal Reserve, a source of adverse-action reasons to the CFPB's Regulation B, an information system holding nonpublic information to NYDFS, and a marketing claim to the FTC. The friction between those two geometries is where most compliance surprises live.

3. Finance: SR 11-7 is your AI governance baseline

The Federal Reserve's SR 11-7, issued April 4, 2011, is the deepest and most battle-tested AI-relevant regime in the US, even though it never mentions AI.^[2] Its attached guidance defines a model as "a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates," with three components: input, processing, and reporting.^[5] A fine-tuned LLM scoring credit memos fits that definition as cleanly as a logistic regression does. If your institution answers to a US banking supervisor, your AI systems are models, and the model risk management apparatus applies.

We cover the discipline itself — validation, effective challenge, remediation, rollback — in depth in /guides/model-risk-management-guide, so this section stays at the decision level. Three SR 11-7 principles do the most work for AI planning. First, materiality scales the obligation: where models materially drive business decisions and model failure would be particularly harmful, "a bank's model risk management framework should be more extensive and rigorous."^[5] That gives you a defensible basis for tiering — the deal-summarization assistant and the underwriting model do not need the same validation depth. Second, vendor models get no pass: all components should be validated, and this "applies equally to models developed in-house and to those purchased from or developed by vendors or consultants."^[5] Third, the third-party relationship around the model is separately supervised: the interagency guidance transmitted as SR 23-4 (June 2023) sets risk management expectations for all stages of the third-party life cycle, and it replaced each agency's prior guidance to make the expectation consistent.^[8] Buying your AI from a frontier lab does not outsource the accountability.

Conduct regulation stacks on top of prudential regulation. Under Regulation B, a creditor must notify an applicant of action on a completed application within 30 days, including the ECOA notice and a statement of specific reasons when the action is adverse^[3] — which converts model explainability from an engineering preference into a hard output requirement for any credit-decisioning AI. And the SEC has signaled where broker-dealer and adviser AI is heading: its July 2023 proposal on predictive data analytics would require firms to eliminate, or neutralize the effect of, conflicts of interest that place the firm's interest ahead of investors' when such technologies are used in investor interactions.^[9] Whatever that rulemaking's final form, the direction is clear — regulators will interrogate what your engagement-optimizing models are optimizing for.

NYDFS Part 500: the cybersecurity overlay on financial AI

New York's Department of Financial Services regulates cybersecurity for the banks, insurers, and other financial firms it licenses through 23 NYCRR Part 500 — and because New York is where much of US financial services is chartered or licensed, Part 500 functions as a de facto national floor. It is a cybersecurity regulation, not an AI regulation, but AI systems fall squarely inside it: the regulation obligates covered entities to run a risk-based cybersecurity program over their information systems and the nonpublic information those systems hold, and an AI platform ingesting customer financial data is exactly such a system.

Structurally, Part 500 requires covered firms to ground their program in periodic risk assessments; to assign accountability to a chief information security officer who reports upward; to control and limit access privileges, including multi-factor authentication; to manage the risk of third-party service providers who touch nonpublic information; to maintain audit trails, monitoring, and incident response capability; and to notify the regulator of qualifying cybersecurity events. Every one of those hooks catches AI infrastructure. Your risk assessment has to account for model endpoints, vector stores, and training pipelines that hold customer data. Access controls and MFA apply to the people and service accounts that can touch models and their data. Third-party provider requirements reach your model API vendors. Incident response has to contemplate AI-specific events — model compromise, data exfiltration through a poorly scoped agent, prompt-injection-driven disclosure. The practical read: do not build a separate "AI security" silo. Extend the existing Part 500 program's inventory, risk assessment, and control set to enumerate AI systems explicitly, so the same evidence that satisfies your NYDFS examination covers your AI estate.

4. Healthcare: FDA regulates the model as the product

Healthcare flips the frame. In finance the AI is an internal tool your supervisor examines; in clinical use the AI can be the regulated product itself. FDA has authorized more than 1,000 AI-enabled devices through its established premarket pathways, and in January 2025 it issued draft guidance that, if finalized, would be the first to provide comprehensive recommendations for AI-enabled device software functions across the total product life cycle, from design and development through post-market maintenance and documentation.^[1] If your organization builds clinical decision software, the strategic consequence is that regulatory strategy is product strategy: intended use, claims, and evidence plans determine which pathway you are in and how fast you can ship.

The most consequential mechanism for AI teams is the predetermined change control plan (PCCP). FDA's final PCCP guidance recommends that a marketing submission describe the planned modifications to an AI-enabled device, the methodology to develop, validate, and implement them, and an assessment of their impact — so that the device can be improved iteratively, within the pre-authorized envelope, while preserving reasonable assurance of safety and effectiveness and without a new marketing submission for each change.^[6] That is the regulator's answer to the core tension of shipping learning systems: models need to be updated, and classical device regulation assumed they would not be. A PCCP negotiated well is a competitive asset — it is the difference between a quarterly model refresh and a re-submission cycle.

Beneath the device layer sits the data layer. The HIPAA Security Rule (45 CFR Part 164) requires covered entities and business associates to ensure the confidentiality, integrity, and availability of all electronic protected health information they create, receive, maintain, or transmit — and its administrative safeguards make a risk analysis mandatory: an accurate and thorough assessment of the risks and vulnerabilities to that ePHI.^[10] Every AI pipeline that touches patient data — training sets, retrieval indexes, transcription buffers, model logs — is inside that obligation, and your existing HIPAA risk analysis must be extended to name those components. The privacy dimensions of AI data handling get full treatment in /guides/personal-data-protection-ai.

5. Critical infrastructure and the cross-sector layer

The cross-sector federal AI layer is currently deregulatory. Executive Order 14179, signed January 23, 2025, revoked prior AI policies characterized as barriers to American AI innovation and set US policy as sustaining and enhancing America's global AI dominance, directing an AI action plan within 180 days.^[7] The resulting plan, released July 23, 2025, lays out more than 90 federal policy actions across innovation, AI infrastructure, and international diplomacy and security.^[4] For operators of energy, water, transportation, and other critical infrastructure, the near-term signal is that AI-specific federal mandates are being pared back while infrastructure build-out is promoted — which means your binding obligations continue to come from the sector reliability, safety, and cybersecurity regimes you already operate under, plus voluntary risk frameworks. The planning implication for a CIO: do not calibrate your AI control posture to the federal AI mood, because sector rules did not move when the executive orders did, and state activity continues on its own track.

One cross-sector enforcer deserves a line item in every AI risk register regardless of industry: the FTC. In September 2024 it announced Operation AI Comply, a sweep of five law enforcement actions against operations that used AI hype or sold AI technology that could be used in deceptive or unfair ways.^[11] The lesson is not about those particular defendants — it is that claims about AI are regulated even where the AI itself is not. Marketing copy that overstates what your AI product does, or an AI-washing claim in a sales deck, is actionable under ordinary consumer protection law. Your review gate for AI product claims should be as rigorous as your review gate for models.

6. RegTech: automating the regulatory work itself

The second half of the decision is operational. A sectoral landscape multiplies regulatory workload — multiple regulators, overlapping obligations, continuous change — and that workload is text-heavy, deadline-driven, and structured: exactly the profile that modern language models automate well. Two RegTech workloads matter most, and they deserve different risk treatments.

Regulatory change management: tracking and summarizing new rules

Change management is the monitoring problem: watching agency publications, proposed and final rules, supervisory letters, and enforcement actions across every jurisdiction you operate in, then routing what matters to the control owners it affects. An LLM pipeline handles the mechanical layers — classifying whether a publication is relevant to your entity type, extracting effective dates and obligations, drafting a first-pass summary and an impact hypothesis mapped to your control inventory. The buying criteria that actually differentiate tools: source coverage and freshness for the specific regulators you answer to (federal plus state, including regimes like NYDFS); provenance — every summary must link the primary text, because a compliance action taken on a hallucinated obligation is itself a compliance failure; jurisdiction and entity-type customization; and integration into the GRC platform where obligations become assigned tasks rather than emailed PDFs. Keep a human compliance reviewer in the loop on anything that changes a control or a filing: the model proposes, the officer disposes.

Regulatory reporting: automating filings

Reporting is the production problem: assembling data from source systems into recurring, format-constrained filings. Automation value concentrates in data lineage and validation — knowing which upstream system produced each reported figure, and proving it — more than in prose generation. The failure mode to design against is silent scale: a manual process produces one wrong filing, an automated one produces a wrong filing every period until someone notices. So the same disciplines you apply to business models apply here — reconciliation checks against source systems, anomaly detection on period-over-period movements, dual control before submission, and a full audit trail from source datum to filed field.

And here the two halves of this guide close into a loop: in a bank, a RegTech model that classifies regulatory changes or drafts filings is itself a model informing business decisions — inside SR 11-7's definition and therefore inside the model risk management framework, at a validation tier matched to its materiality.^[5] If the automated filing feeds your supervisor, its failure is material almost by definition. Govern the compliance AI with the same apparatus the compliance AI exists to serve; a vendor RegTech model additionally inherits the third-party life cycle expectations of SR 23-4.^[8]

7. The honest objections

"SR 11-7 is guidance, not law — and it only binds banks." True on both counts. It is supervisory guidance, its force runs through the examination process, and a retailer or SaaS company owes it nothing. The counterpoint is practical: it is the most complete, examiner-tested articulation of how to govern consequential models that any US authority has produced, its concepts (independent validation, effective challenge, materiality tiering) transfer to any high-stakes AI deployment, and regulated buyers increasingly push its expectations onto their AI vendors through diligence. Adopting its skeleton voluntarily is cheaper than inventing your own and easier to defend to any regulator you do meet.

"The sectoral patchwork leaves gaps — most enterprise AI falls into none of these regimes." Also true. A marketing-content model at an unregulated company sits under general consumer protection and little else, and the US approach genuinely does leave uneven coverage compared with the EU's horizontal act. But the objection cuts the other way for planning: gaps are where rules will eventually land, at the federal or state layer, and the cheapest hedge is an AI inventory tagged by sector exposure so that when a rule arrives you already know which systems it touches. The FTC's claims enforcement also reaches into the "unregulated" zone today.^[11]

"Automating compliance with AI just adds model risk to compliance risk." Correct — and the reason to do it anyway is that the manual baseline is not risk-free either; it is slow, inconsistent, and unauditable at today's regulatory volume. The honest framing is a risk exchange: you trade human error and latency for model error at scale, and the exchange is favorable only when the automation carries validation, monitoring, human sign-off on consequential outputs, and rollback. Treat any RegTech deployment that lacks those as adding risk, not removing it.

8. The read

Sectoral regulation rewards enterprises that map early and centralize evidence. The decision this guide supports is architectural: build one AI inventory and one controls-and-evidence backbone, then project it into each sector regime you face — SR 11-7 tiers and validation records for the banking supervisor, Part 500-aligned security evidence for NYDFS, device documentation and a PCCP for FDA, HIPAA risk analysis coverage for the data layer, and a claims-review gate for the FTC. Buy or build RegTech to automate the tracking and reporting load, and govern that automation with the same discipline. The enterprises that struggle are the ones that stand up a parallel compliance apparatus per regulator; the ones that cope run one governed AI estate with many regulatory projections of it.

9. How to apply this