What Regulation Changes in an AI Project
Regulation changes where data can go, what you must explain, and how long you keep it. It changes little else. Two current examples, HIPAA cloud guidance and the April 2026 replacement of SR 11-7, show what the constraints look like and how fast they move.
- ai-regulation
- compliance
- data-governance
- ai-projects
- risk-management
Regulation changes three things about an AI project: where the data can go, what you have to be able to explain, and how long you keep it and who can see it. It changes very little else. The mistake we see most is treating "regulated" as a reason to run a different method, when the method is the same and the constraints arrive earlier.
Two current examples show what the constraints look like in practice, and how quickly they move.
What actually changes
Where data can go. This is the constraint buyers assume is a wall and is usually a door with conditions. HHS's guidance on cloud computing says a HIPAA covered entity may use a cloud service provider to store or process electronic protected health information, provided it enters into a HIPAA-compliant business associate agreement. HHS adds that this applies even if the provider can't decrypt the data, and that storing it on servers outside the US is also allowed under the same agreement, while warning that the risks vary with geography and belong in your risk analysis. That page was last reviewed in December 2022, so check for updates. The point holds: the first question isn't "can we use AI?" It's "what data is involved, and under what agreement can it go where?"
What you have to explain and validate. In US banking, the Federal Reserve's SR 26-2, dated 17 April 2026, supersedes and replaces SR 11-7, the 2011 model risk management guidance. The Fed's letter says it's expected to be most relevant to banking organizations with more than $30 billion in assets. A footnote in the guidance itself says generative AI and agentic AI models are "novel and rapidly evolving" and "are not within the scope of this guidance," while noting that a bank's risk management and governance practices should still guide the controls for such tools. Davis Polk's memo of 27 April 2026 adds that the agencies plan to seek input on them, though we haven't found that commitment in the Fed's own text. What it means for a buyer is plain enough: no one can hand you a finished validation standard for a generative system, so you need to write your own, document it, and be able to show an examiner or auditor how outputs are checked.
Retention and access. Regulated data carries retention windows and access-logging duties that a general-purpose build won't satisfy by default. These belong in the architecture from the start. Retrofitting an audit trail onto a running system is slower and more expensive than designing one.
Notice the dates. Guidance that governed banks for 15 years was replaced six months ago. The European Commission announced a political agreement on 7 May 2026 under which AI rules for systems in areas such as employment and education would apply from 2 December 2027. We haven't confirmed formal adoption. Anyone quoting you a compliance requirement should be able to name the document and its date.
What doesn't change
Discovery works the same way. You still map the workflow, find the decision points, and quantify the return. Regulation takes some workflow types off the table. It doesn't make finding the good ones harder.
The way you evaluate an agency doesn't change either. Documented method, a track record you can verify, and a handover deliverable all still apply. Experience in your sector is an additional filter on top of those, not a substitute for them.
Ownership still has to be internal. Compliance owns the external requirements. Someone else has to own what the system does after launch, who watches the outputs, and who gets the call when something goes wrong.
Price is the one to watch. Nothing in the sources above puts a multiple on regulation. If a quote carries a regulated-industry premium, ask to see it as line items: extra design time in the first weeks, extra testing, extra documentation. Those are fair. An unexplained multiplier isn't.
Three myths, and a test for each
"Compliance won't let us use AI." Test: ask compliance to name the specific rule and the specific data category. HHS's own page shows the real answer is usually conditions, not a ban.
"We need a custom model to stay compliant." Test: ask which requirement the custom model satisfies that a hosted or self-run existing model can't. If the answer is data residency, there may be simpler ways to meet it. A custom model is also what a longer engagement looks like from the agency's side.
"Legal must approve every build." Test: ask legal to write down what the system can't do and which data it can't touch, then design inside that. Reserve case-by-case review for the high-risk decisions, such as credit, clinical support or regulatory reporting.
Scope it in week one
Three questions, answered on one page before design starts: which data categories are involved, where can each one go and under what agreement, and what must be explainable about each output. Put a name next to each answer.
Take whatever AI project you're planning or running and try to fill that page today. If you can't, the project isn't scoped yet, however far along the build is. Sector-specific versions of this will follow.
If you want that question answered for your specific situation, the Forge Playbook does it. Answer a few questions about your business and we'll put together a tailored outline of which workflows are worth automating and what a realistic budget looks like for each. Free, no obligation, takes about three minutes.
