OQ-001
Rule silent
Letter drafted May 19, 2026. Pending filing.
HIPAA Security Rule cascade through multi-tier business associate relationships with AI vendors
45 CFR 164.308(b) and 164.314(a) require a covered entity to obtain satisfactory assurances from a business associate that the BA will appropriately safeguard ePHI. 164.308(b)(2) then requires the BA to obtain the same assurances from its subcontractors that create, receive, maintain, or transmit ePHI. The rule says nothing about how far this cascade runs when an AI vendor sits two or three tiers below the covered entity. A health system using an EHR vendor that uses an analytics platform that uses an LLM API faces an ambiguous BA chain.
What the rule says
The Security Rule imposes BA obligations on each tier in the chain that creates, receives, maintains, or transmits ePHI. It does not state how documentation, breach notification timing, or termination clauses propagate downstream when the third-tier vendor (an LLM API provider, for example) processes de-identified inputs that may incidentally re-identify in context.
45 CFR 164.308(b) and 164.314(a); HHS HIPAA Privacy and Security Rule Compliance Notice on Use of Online Tracking Technologies (March 2024); proposed Security Rule NPRM at 90 FR 898 (Jan 6, 2025)
Common position
Most healthcare CISOs treat the third-tier AI vendor as out of scope when inputs are de-identified at the second tier under 164.514(b)(2), and rely on the safe-harbor de-identification standard. They sign BAAs at tier one and tier two only.
Dissenting view
A growing minority of OCR-trained privacy attorneys argue that the Privacy Rule's "minimum necessary" standard and the proposed Security Rule expansions (90 FR 898) require BAAs at every tier where an LLM could re-identify in context (rare combinations of demographics, narrative free-text, regional specificity). They sign BAAs through the full chain.
Our position
For health-data workloads that include free-text or narrative content, do not rely on the safe-harbor de-identification standard alone. The combination of context, region, and narrative is sufficient for an LLM to re-identify in well-documented edge cases. Push the BAA cascade through the full chain. If a tier refuses to sign, switch vendors or route the workload through a BA-eligible AI-for-Healthcare tier (Anthropic Claude for Healthcare, OpenAI Healthcare enterprise, Google Healthcare, Microsoft Azure HIPAA-eligible services).
The specific question we would file
Addressee
HHS Office for Civil Rights (HHS OCR)
Question presented
When a covered entity's data flow involves three or more tiers (covered entity → first-tier BA → second-tier subcontractor → third-tier AI service provider), does 45 CFR 164.308(b)(2) require a written BAA at each tier where the entity could create, receive, maintain, or transmit ePHI through re-identification by combination, even if the upstream tier applies safe-harbor de-identification under 164.514(b)(2)? And does the proposed Security Rule NPRM (90 FR 898) intend to clarify this cascade or leave it as a documentation question?
OQ-002
Rule silent
Letter drafted May 19, 2026. Pending filing.
NIST AI RMF operational status and federal agency adoption posture after EO 14110 rescission
NIST AI RMF 1.0 was published January 2023 as a voluntary framework. EO 14110 (October 2023) made AI RMF the federal default and tasked OMB with implementation guidance. Trump's January 23, 2025 executive order rescinded EO 14110 and superseded its key implementing memos. OMB M-26-05 (January 23, 2026) is now the operative guidance document. Whether NIST AI RMF remains the federal default, whether agency CAIOs must align with it, and whether contractors selling to federal agencies should treat it as a baseline are now unclear.
What the rule says
NIST publications are voluntary frameworks unless adopted by a binding instrument (statute, regulation, executive order, OMB circular, contract clause). EO 14110 made AI RMF the federal default for many agency obligations. Its rescission removed that anchor. OMB M-26-05 is the current operative memo. M-26-05 does not republish the AI RMF alignment language that lived in OMB M-24-10.
NIST AI RMF 1.0 (January 26, 2023); EO 14110 (October 30, 2023, rescinded); Trump EO of January 23, 2025; OMB M-26-05 (January 23, 2026)
Common position
Most federal CAIOs and contracting officers treat NIST AI RMF as a continuing baseline expectation, on the theory that NIST publications survive executive order changes and the framework remains the most coherent federal AI risk vocabulary. Vendors selling to federal agencies still align proposals to AI RMF Govern / Map / Measure / Manage categories.
Dissenting view
A minority of federal AI compliance counsel argues that without EO 14110's anchoring language, AI RMF is back to its pre-October-2023 voluntary status, and that contractors should not represent AI RMF alignment as "federal default" in proposals. The proper framing is "industry standard the agency may or may not require."
Our position
Continue aligning federal AI proposals to NIST AI RMF Govern / Map / Measure / Manage. The framework itself was not rescinded. The anchoring EO was. Until OMB publishes successor guidance that names a different framework, AI RMF remains the only coherent federal AI risk vocabulary. Treat it as industry standard, not as a regulatory mandate, in proposal language. Match agency-specific requests, not assumed defaults.
The specific question we would file
Addressee
NIST AI Office and OMB Office of Federal Procurement Policy (OFPP)
Question presented
Following the January 23, 2025 rescission of EO 14110 and the supersession of OMB M-24-10 by OMB M-26-05, what is NIST's current view on AI RMF's operational status for federal agencies and federal contractors? Specifically, does NIST intend to publish a Federal Profile of AI RMF (as suggested in the 2024 generative AI companion document) that anchors agency adoption independent of any executive order, and how should contractors selling to federal agencies represent AI RMF alignment in proposals during this transition period?
OQ-003
Rule silent
EU AI Act extraterritorial reach for U.S. SaaS firms with EU-resident users but no EU establishment
EU AI Act Article 2(1) extends the Regulation to providers placing AI systems on the market or putting them into service in the Union, regardless of where the provider is established. The Regulation also reaches providers and deployers established outside the Union if the output produced by the AI system is used in the Union. The phrase "placing on the market" has a specific Regulation 765/2008 meaning. What it means for a U.S. SaaS company that does not market in the EU but whose users include EU residents who self-onboard is unclear.
What the rule says
Article 2(1)(a) covers providers placing AI systems on the EU market or putting them into service in the EU. Article 2(1)(c) covers providers and deployers established outside the Union where output is used in the Union. The Regulation does not define a de minimis EU-user threshold below which extraterritorial reach lapses.
Regulation (EU) 2024/1689 (EU AI Act) Article 2(1)(a), (c); Regulation (EC) 765/2008 (definition of "placing on the market"); European Commission AI Office guidance fragments (2025-2026, partial)
Common position
Most U.S. SaaS general counsels treat passive availability to EU users (no EU marketing, no EU pricing, no EU-localized terms) as outside Article 2(1)(a). They focus on Article 5 prohibited practices and rely on the absence of EU marketing to defeat the "placing on the market" element.
Dissenting view
A minority of EU-data-protection counsel reads Article 2(1)(c) as catching any U.S. SaaS firm whose AI output reaches EU users in any volume, treating "output used in the Union" as a self-executing trigger that does not require EU marketing. Under this reading, even passive EU users would pull a U.S. firm into transparency, risk-classification, and post-market monitoring obligations.
Our position
For U.S. firms with intentional EU customers (EU pricing, EU localization, EU sales motion), treat the AI Act as applicable. Build out Article 13 transparency and Article 51 GPAI obligations if relevant. For U.S. firms with incidental EU users (single-language English product, no EU marketing, no EU contracts, EU users self-onboard), the rule is genuinely ambiguous. Document the de minimis posture in your data map and model card. Monitor AI Office guidance through 2026 for the threshold question. Do not assume passivity equals non-application.
The specific question we would file
Addressee
European Commission AI Office (DG CONNECT)
Question presented
Under Article 2(1)(a) and (c) of Regulation (EU) 2024/1689, does extraterritorial application attach to a non-EU provider whose AI system is not marketed in the Union, has no EU-localized terms or pricing, and is accessed only by self-onboarding EU-resident users? Does the AI Office intend to publish a de minimis threshold or a "directing activities to the Union" test analogous to GDPR Article 3(2)(a) case law (e.g., Bolagsupplysningen and Schrems II reasoning)?
OQ-004
Rule silent
SOC 2 treatment of third-party LLM APIs: vendor management versus subservice organization
When a service organization uses a third-party LLM API (OpenAI, Anthropic, Google) as part of the service it provides to user entities, AICPA Trust Services Criteria do not directly address whether the LLM provider is a vendor (managed under CC9.2 third-party risk) or a subservice organization (carve-out or inclusive treatment under the SOC 2 reporting framework). The distinction drives evidence collection, report format, and management assertion scope.
What the rule says
CC9.2 requires the entity to assess and manage risks associated with vendors and business partners. The SOC 2 Reporting Guide defines a subservice organization as a service organization used by another service organization to provide services that are likely to be relevant to user entities' internal control. Whether an LLM API meets the "likely to be relevant" threshold is judgment-driven and the AICPA has not published an authoritative position.
AICPA Trust Services Criteria 2017 (CC9.2 Vendor Management); AICPA SOC 2 Reporting Guide; SSAE 18 AT-C Section 205
Common position
Most SOC 2 practitioners treat LLM APIs as vendors under CC9.2. They document the API in the vendor inventory, perform a security review, and consume the vendor's SOC 2 or ISO 27001 report. They do not name the LLM provider as a subservice organization in management's description of the system.
Dissenting view
A minority of practitioners (and some Big 4 audit teams) treat the LLM provider as a subservice organization, requiring either carve-out treatment (with complementary user entity controls disclosed) or inclusive treatment (with the LLM provider's controls audited as part of the engagement scope). The argument is that the LLM is performing a core process step on customer data, not providing peripheral infrastructure.
Our position
If the LLM API call processes customer data on the path to the service output (LLM-generated content delivered to the user, LLM-driven decisions, LLM-derived metadata stored in customer records), treat the LLM provider as a subservice organization. Most service organizations meet this fact pattern. The carve-out posture with named complementary user entity controls is the cleanest path. If the LLM API is used only for internal operations (developer tooling, marketing copy, internal analytics) and customer data does not transit it, CC9.2 vendor management is sufficient.
The specific question we would file
Addressee
AICPA Assurance Services Executive Committee (ASEC) and SOC Reporting Task Force
Question presented
Will the AICPA Assurance Services Executive Committee publish guidance on whether a third-party LLM API provider that processes customer data on the path to a service organization's output should be treated as a subservice organization under the SOC 2 Reporting Guide, and if so, the criteria distinguishing subservice organization treatment from CC9.2 vendor management?
OQ-005
Rule silent
NIST SP 800-171 Rev 2 vs Rev 3: which revision governs a CMMC Level 2 assessment scheduled during the transition window
NIST SP 800-171 Rev 3 was published May 14, 2024. DFARS clause 252.204-7012 does not name a revision number. DoD policy and 32 CFR 170 currently anchor CMMC Level 2 to Rev 2 as the operative baseline. A pre-assessment readiness review built against Rev 3 may flag controls (3.1.20, 3.4.12, 3.13.13 expansions) that the C3PAO does not actually score. A review built against Rev 2 may miss organizational supply-chain control language that Rev 3 added.
What the rule says
DFARS 252.204-7012(b)(2)(i) requires the contractor to implement "NIST SP 800-171 in effect at the time the solicitation is issued or as authorized by the Contracting Officer." 32 CFR 170 fixes CMMC Level 2 to "NIST SP 800-171 Rev 2." DoD has not published a class deviation moving CMMC L2 to Rev 3. The rule is internally consistent only if "in effect" reads to mean "in effect for CMMC L2 purposes per DoD policy," which is Rev 2.
DFARS 252.204-7012; NIST SP 800-171 Rev 2 (January 2020 with February 2020 updates); NIST SP 800-171 Rev 3 (May 14, 2024); 32 CFR 170 (CMMC Program); DoD class deviations through 2026
Common position
Most CMMC practitioners assess against Rev 2 controls and Rev 2 control numbering. They reference Rev 3 as a forward-looking baseline for SSPs that may need to migrate when DoD publishes a class deviation.
Dissenting view
A minority of CISO practices (and some primes pushing supply-chain language down to subs) assess against Rev 3, on the theory that Rev 3 is "in effect" within the meaning of DFARS 252.204-7012(b)(2)(i) once NIST publishes it, and that Rev 2 has been formally superseded for SP 800-171 purposes even if CMMC L2 has not moved.
Our position
Assess against Rev 2 for CMMC Level 2 readiness. The C3PAO will score against Rev 2. Maintain a Rev 3 gap analysis as a forward-looking artifact (DoD will publish a class deviation moving CMMC L2 to Rev 3 within 12 to 24 months based on the cadence of prior revisions). For new SSPs being drafted after September 2026, build the document to Rev 3 control numbering and back-map to Rev 2 for current scoring, rather than the reverse. The back-map direction matters because Rev 3 controls are a superset.
The specific question we would file
Addressee
DoD CIO and Defense Industrial Base Cybersecurity Assessment Center (DIBCAC)
Question presented
For a CMMC Level 2 assessment scheduled in Q3 or Q4 2026, will the C3PAO score against NIST SP 800-171 Rev 2 (the version named in 32 CFR 170) or against NIST SP 800-171 Rev 3 (the version "in effect" at the time of solicitation under DFARS 252.204-7012(b)(2)(i))? And does DoD intend to publish a class deviation moving CMMC Level 2 to Rev 3, and if so, on what notice period to the contractor base?