Skip to content

Public sector & regulated industries

Audience. CISO at a bank, insurer, or health system; public-sector CTO; FedRAMP / HIPAA / PCI / GDPR / NIS2 / DORA-EU-bound program owner; defense / national-security cleared programs. Constraints. Legal liability is direct. Regulators issue specific, enforceable guidance. Some classes of customer or citizen data have absolute restrictions. Vendor "enterprise tier" assurances are not, by themselves, sufficient.

The regulated tier is not "enterprise plus paperwork." It is a different risk model in which the floor for every governance pillar is set externally (by a regulator, a sector standard, or a statute) and the program's job is to demonstrate compliance, not to design it from first principles. Many of the framework's recommendations that are aspirational at enterprise tier (e.g., logging every prompt-response pair) are mandatory here.

This page does not constitute legal advice

Sector regulations change. Specific obligations depend on jurisdiction, role (controller vs. processor, provider vs. deployer), and contractual context. Treat this page as a structured set of questions to take to qualified counsel, regulators, and your Privacy/Risk function, not as a substitute for them.

Regulatory landscape (as of 2026)

The regulated-tier program operates within a stack of overlapping obligations. The framework groups them into four layers; specific controls map onto multiple layers simultaneously.

Cross-sector AI-specific

  • EU AI Act: Regulation (EU) 2024/1689. Risk classification of AI systems (unacceptable / high-risk / limited / minimal); obligations on providers and deployers; transparency, logging, conformity assessment, post-market monitoring1.
  • NIST AI Risk Management Framework and the GenAI Profile (NIST AI 600-1): voluntary in the US, but increasingly referenced contractually and by US federal procurement guidance23.
  • ISO/IEC 42001:2023: AI management system standard, designed for certification4.

Sector-specific

Sector Instrument What changes for AI tooling
US health (HIPAA-covered) HIPAA Privacy & Security Rules; HHS guidance on AI5. PHI never leaves a Business Associate boundary; BAA required with any AI vendor that processes PHI; minimum-necessary applies to prompts.
Payments PCI DSS 4.06. Card data never enters a prompt; tokenisation upstream; logging requirements apply to AI-touched paths.
US financial services FFIEC IT Handbook; OCC, FRB, FDIC supervisory guidance on third-party risk and gen-AI7. Third-party risk management treats AI vendors as critical providers; model risk management (SR 11-7-style) applies to AI-assisted code that materially affects models or risk systems.
EU financial services DORA (Digital Operational Resilience Act)8. ICT third-party risk register, exit strategy, incident classification, threat-led penetration testing for critical providers.
EU critical infrastructure NIS2 Directive9. Incident reporting timelines; supply-chain security; management-body accountability.
US federal FedRAMP authorisation; OMB M-24-10 / AI use-case inventory10. Agency-wide AI use-case inventories; FedRAMP-authorised hosting; data residency; FOIA-aware logging.
UK public sector Algorithmic Transparency Recording Standard; ICO AI guidance11. Transparency register entries for AI used in public-facing services; DPIA mandatory for high-risk processing.
Defense / national security National classification rules; export controls. Per-jurisdiction; AI tooling typically restricted to authorised classified-environment platforms only.

Privacy / data-protection

  • GDPR (EU/UK): lawful basis, DPIA where high-risk processing is involved, controller / processor distinction, cross-border transfers via SCCs / adequacy / DPF12.
  • State-level US privacy (CCPA/CPRA, Virginia, Colorado, etc.): varying definitions of sensitive personal data and opt-out rights for automated decisions13.
  • Sectoral privacy (e.g., GLBA for US financial, FERPA for US education): narrower obligations layered on top.

Public-record / transparency

  • FOIA (US federal) and equivalents in UK, EU member states, etc. Affects what can be logged about citizen interactions and what must be discloseable on request.
  • Algorithmic-transparency obligations in some jurisdictions (e.g., UK ATRS, NYC Local Law 144 for employment decisions).

What "in scope" means in regulated contexts

Every workload class needs an explicit AI classification. The framework's risk classification matrix is necessary but not sufficient at this tier; it is paired with a workload-class register that tags each material system.

Tag Definition Examples
AI-allowed AI tooling is permitted under standard controls. Internal-only tools, non-customer-facing utilities, public-content systems.
AI-with-controls AI tooling is permitted under named additional controls (specific tools only, prompt logging mandatory, second reviewer, no autonomous write). Most customer-facing systems below Critical tier.
AI-prohibited No AI tooling on this code path or against this data class. Systems handling regulated data classes the program has not yet contracted for; classified or export-controlled environments without an authorised AI platform; safety-critical decision points.

The register is owned by Risk, signed by the BU, and refreshed on the risk classification re-classification cadence.

What an AI-prohibited tag actually prevents

A bank's mortgage underwriting decision engine may be tagged AI-prohibited for code on the decision path, even though AI tools are allowed elsewhere in the same repository. The platform-level controls then prevent the engine's source files from being sent to any model endpoint. The prohibition is only meaningful if it is enforced at the platform layer; a policy-only prohibition is not auditable.

Data residency and cross-border inference

A model endpoint is a processing location. Sending a prompt that contains regulated personal data from the EU to a US model endpoint is a cross-border data transfer subject to the GDPR's transfer rules, regardless of whether the response is stored. Treating model endpoints as "just an API" is a common and costly category error.

Minimum residency controls at this tier:

  • Per-tool, per-region inventory. Document which approved tools have endpoints in which regions, and which regions are approved for which data classes.
  • Lawful-basis assessment per processing activity. For each AI tool use case, document the legal basis (consent, contract, legitimate interest, public task), the controller/processor relationship, and any transfer mechanism (SCCs, adequacy, sector-specific).
  • DPIA where required. For high-risk processing (extensive personal data, automated decisions, vulnerable subjects, novel technology), a Data Protection Impact Assessment is mandatory under GDPR. AI-assisted development that processes personal data for the first time often triggers this.
  • Egress controls at the platform. Network-layer enforcement that prompts containing regulated data classes only reach approved endpoints in approved regions. DLP rules pre-egress, fail-closed by default.

Public-sector specifics

Public-sector adoption has constraints that do not appear in commercial contexts.

Procurement constraints

  • FedRAMP authorisation (US federal): AI tools used for federal workloads must be hosted under FedRAMP-authorised arrangements, with ATO (Authority to Operate) per agency.
  • G-Cloud (UK) and equivalent procurement frameworks: pre-vetted vendors, standard terms, transparency obligations.
  • Open-source preferences: some jurisdictions and agencies have formal preferences for open source where viable; this can affect tool selection and self-hosting decisions.

FOIA and public-record obligations

If a public body uses an AI assistant to draft code, the prompts and responses may be subject to public-record requests. The implications:

  • Don't log what cannot be released without a redaction process. Alternatively, log into a system with FOIA-aware redaction tooling.
  • Treat prompt content as a record for retention scheduling purposes, aligned with the agency's records schedule.
  • Train staff that drafting-assistant prompts are not private scratch-pads in a public-record context.

Algorithmic-transparency registers

Where applicable (UK ATRS, NYC LL144, equivalent local rules), the use of AI in public-facing services may need to be entered in a public register. The framework's regulatory mapping includes templates for the most common registers.

Audit evidence: every AI-touched commit reconstructable

The evidentiary bar at regulated tier is that for any AI-touched commit, an auditor can reconstruct: who made it, with which tool, against which model version, with which prompt class, and under which AUP clause. That sentence is the simplest summary of what Audit trail prescribes at this tier.

The capture pipeline:

Capture point What Where
Identity User, role, BU. SSO logs, joined to commit author.
Tool & session Which tool, which session ID, which model version (or model family + region). Tool-side logs, exported to central store.
Prompt class Tagged classification (refactor, generate, explain, etc.) per the prompt taxonomy in S.C.A.F.F.. Tool-side or wrapper log; aligns with the AUP's permitted-use clauses.
Diff annotation PR-level: AI-assisted yes/no, primary tool, optional pointer to prompt session. Repo metadata.
Verification artifacts Test results, AppSec review evidence, exception approvals. CI + ticketing system.
AUP clause Which AUP clause permitted the use; which exception, if any, applies. AUP version reference + exception register.

Retention is set per regulator. Common floors:

  • GDPR / employment data: record-keeping minima per local rules, often 3–6 years.
  • PCI DSS: at least 1 year, with last 3 months immediately available.
  • HIPAA: 6 years from creation or last effect.
  • FFIEC / SR 11-7-equivalent model documentation: life of the model + agreed period; commonly 7 years.
  • DORA: varies; ICT-third-party register and incident records have specific obligations.

Frameworks at regulated: all eight, all enforced

Framework Regulated posture
S.C.A.F.F. Prompt taxonomy is authoritative; logged prompts are tagged against it.
V.E.R.I.F.Y. Level 3 is the default for any High/Critical workload; Level 1 is the floor everywhere else.
S.E.C.U.R.E. AppSec review is mandatory pre-merge for security-sensitive paths; evidence retained.
S.H.I.E.L.D. Mandatory, not aspirational. Sandboxed agents, allow-listed endpoints, controlled egress, DLP.
C.L.E.A.R. Two reviewers minimum on AI-touched merges; named reviewer roles per tier.
R.E.F.A.C.T. Refactor budget is allocated and tracked; legacy modernisation projects with AI assistance go through additional risk review.
D.O.C.S. ADRs are mandatory for AI-assisted changes; ADRs themselves are audit evidence.
C.O.D.E.S. Pairing patterns and review rituals are documented; training is logged per individual.

The single most important difference from enterprise tier: the stop conditions are stricter and more numerous, and they trigger automatically rather than discretionarily.

Stop conditions

Automatic stop conditions at regulated tier

The following events trigger an immediate program pause, with notification to the named exec sponsor and (where applicable) the regulator-facing function within hours:

  • Any prompt egress containing classified, regulated, or contractually restricted data classes, regardless of whether the egress was successful or blocked.
  • Any AI-generated change deployed to production on an AI-prohibited workload class.
  • Any vendor sub-processor change without prior notice as required by DPA.
  • Any incident response (AI-adjacent) reaching the regulator notification threshold (e.g., GDPR 72-hour, NIS2 24-hour initial / 72-hour update, sector equivalents).
  • Any model or endpoint change that moves inference outside the approved residency footprint.
  • Any audit finding that the audit trail is non-reconstructable for a material time window.

"Pause" means: stop new AI-tool sessions, freeze approved-tool list, convene IR + Risk + Legal within the response window, and produce a written go/no-go before resumption.

These stop conditions are not optional. They are the mechanism by which the program defends its right to operate; a regulated organization that could have stopped and did not faces compounding liability that a prompt pause would have prevented.

Common failure modes

Regulated patterns to avoid

  • Assuming the vendor's enterprise tier satisfies your regulator. It does not. The vendor offers a contract; your regulator expects your program to demonstrate control of the processing. SOC 2 on the vendor is a useful input, not a substitute for your own attestation.
  • Accepting "trust me" assurances. A no-train commitment without a signed DPA, sub-processor list, and notice clause is not an assurance; it is a marketing line. Regulators will ask for the paper, not the press release.
  • Treating AI tools as developer tools rather than data-processing systems. A code assistant that processes prompts is, in privacy terms, a data processor. Inventory it as such, contract it as such, and audit it as such.
  • Building the workload-class register from the policy down rather than from the data up. Tag the data first; the workloads inherit the strictest tag of the data they touch.
  • Conflating "we have an AUP" with "we have controls." An AUP is a paper artifact. Platform-enforced egress controls, allow-listed endpoints, and centralised logging are controls. A regulator distinguishes them; the program should too.
  • Letting an unrelated AI initiative (chatbots, marketing copy) drag the coding program into a higher risk tier than its scope warrants. Keep the AI-coding program's regulatory footprint explicit and bounded; it should not inherit obligations from unrelated AI use cases unless it shares data flows with them.
  • Forgetting the FOIA / public-records angle. Public-sector programs that log every prompt for audit purposes can find those prompts in a public-records request later. Plan the logging architecture with redaction in mind from day one.
  • Underestimating the timeline. A regulated AI-coding program from charter to scaled operation typically takes 18–24 months. Compressing it to a quarter produces unsafe defaults. Phase 0 doubles in this tier.

A regulated 24-month rollout sequence

Phase Months Key moves
Pre-charter -3 to 0 Regulator engagement (where appropriate); DPIA scoping; workload-class data-tag inventory.
Phase 0: Readiness 0–6 Charter; AUP framework; risk classification; vendor RFP with regulator-grade attestations; platform-control architecture.
Phase 1: Pilot 6–12 One BU, AI-with-controls scope only. Full audit trail from day one. Mid-pilot regulator briefing if applicable.
Phase 2: Scale 12–18 Selected BUs with go decision; S.H.I.E.L.D. platform fully enforced; first audit (internal); first board / regulator-aligned report.
Phase 3: Optimize 18–24 Steady state; quarterly reviews; annual regulator-aligned report; framework reviews; vendor re-attestation cycle.

The timeline is not negotiable downward without a corresponding narrowing of scope. A 12-month regulated rollout is a 24-month rollout that has skipped half its sign-offs.

Cross-references

Next

  • If you have not yet engaged your regulator-facing function on the AI program, that is the first conversation. The framework's regulatory mapping is the briefing artifact.
  • If you do not yet have a workload-class register, build it before selecting tools. Tool selection that precedes data classification is almost always re-done.
  • If your program is already running and you are unsure it would reconstruct on audit, run a tabletop using the incident tabletop worksheet with an "auditor request" scenario.

  1. European Union, Regulation (EU) 2024/1689 (AI Act), Jul 2024 [primary]. ↩

  2. NIST, AI 100-1: AI Risk Management Framework, Jan 2023 [primary]. ↩

  3. NIST, AI 600-1: Generative AI Profile, Jul 2024 [primary]. ↩

  4. ISO, ISO/IEC 42001:2023 [primary]. ↩

  5. U.S. Department of Health & Human Services, HIPAA Privacy and Security Rules [primary]; HHS OCR guidance on AI is updated periodically. ↩

  6. PCI Security Standards Council, PCI DSS v4.0, Mar 2022 [primary]. ↩

  7. Federal Financial Institutions Examination Council, IT Examination Handbook [primary]. ↩

  8. European Union, Regulation (EU) 2022/2554 (DORA), Dec 2022 [primary]. ↩

  9. European Union, Directive (EU) 2022/2555 (NIS2), Dec 2022 [primary]. ↩

  10. U.S. Office of Management and Budget, M-24-10: Advancing Governance, Innovation, and Risk Management for Agency Use of AI, Mar 2024 [primary]. ↩

  11. UK Information Commissioner's Office, Guidance on AI and data protection, refreshed periodically [primary]. ↩

  12. European Union, Regulation (EU) 2016/679 (GDPR) [primary]. ↩

  13. Aggregated coverage in the evidence pack; consult counsel for current scope. ↩