University Research and the Federally Funded Project AI Compliance Stack

University Research and the Federally Funded Project AI Compliance Stack

Universities running federally funded research projects have quietly accumulated one of the most complex compliance surfaces in any sector. A single lab might handle student records protected by FERPA, generate controlled unclassified information (CUI) subject to CMMC requirements, and operate under NIH data management and sharing policies that took effect January 25, 2023. Layer AI tools on top of that, and you get a compliance stack that most institutional review processes were never designed to evaluate.

Let's walk through how these three frameworks interact, where the friction points are, and what it actually takes to deploy AI in this environment without creating audit nightmares.

FERPA: The Baseline That Touches Everything

FERPA (20 U.S.C. § 1232g) protects education records, and its reach in a research university is broader than people tend to assume. If a graduate student working on a federally funded project is also enrolled as a student, their participation records, evaluations, and certain communications can qualify as education records. The "school official" exception under 34 CFR § 99.31(a)(1) allows disclosure to university employees with a legitimate educational interest, but that exception gets complicated fast when AI systems are processing data.

The core question: does feeding student-adjacent data into an AI tool constitute a "disclosure" to a third party? If the AI vendor has access to the data, even for model training or logging purposes, the answer is almost certainly yes. The Department of Education's 2023 guidance on ed-tech vendors reinforced that third-party service providers must be under "direct control" of the institution and subject to FERPA's use and redisclosure restrictions. A general-purpose LLM API with standard commercial terms does not meet that bar.

For research teams, this means any AI tool that touches data involving student participants needs to be vetted not just through IRB protocols but through FERPA compliance review. Many universities are still treating these as separate tracks, which creates gaps.

CMMC: When Defense Dollars Enter the Lab

The Cybersecurity Maturity Model Certification program has been rolling toward full implementation under 32 CFR Part 170, with the final rule published in October 2024. Universities with Department of Defense contracts or subcontracts that involve CUI now face CMMC Level 2 requirements at minimum, which maps to all 110 controls in NIST SP 800-171 Rev 2.

Here is where it gets interesting for AI. CMMC's access control family (AC) and audit and accountability family (AU) impose requirements that most AI tools violate by default. Consider AC-3 (access enforcement) and AC-4 (information flow enforcement). If a researcher uses an AI assistant to summarize CUI data, and that data transits to a cloud endpoint outside the university's assessed boundary, you have a potential CMMC violation. The same applies to AU-3 (content of audit records); most commercial AI tools do not generate audit logs at the granularity CMMC assessors expect.

DFARS clause 252.204-7012 has been in contracts since 2017, but enforcement was inconsistent. CMMC changes that by requiring third-party assessments. Universities that have been self-attesting to NIST 800-171 compliance are now facing actual audits. Georgia Tech's $4.3 million False Claims Act settlement in 2024, related to cybersecurity compliance failures on DoD contracts, should be a wake-up call for any research institution that has been treating these requirements as aspirational.

AI tools used in CUI-adjacent workflows need to operate within the CMMC assessment boundary, or the institution needs to demonstrate that CUI never enters the AI pipeline. Both options require architectural decisions, not just policy documents.

NIH Data Sharing Policy: The Newest Layer

The NIH Data Management and Sharing Policy (NOT-OD-21-013), effective since January 2023, requires that all NIH-funded research produce a data management and sharing plan. This policy explicitly covers data generated during the research process, and it creates a tension with both FERPA and CMMC.

NIH expects scientific data to be shared in repositories, but FERPA-protected data and CUI cannot simply be deposited in public or semi-public repositories without additional controls. De-identification under FERPA's standards (which reference the HIPAA Safe Harbor and Expert Determination methods, per Department of Education guidance) is one path, but AI-generated derivatives of protected data raise novel questions. If an AI model produces a summary or analysis of FERPA-protected records, is the output itself an education record? The Department of Education has not issued definitive guidance on this, but the conservative read, and the one most institutions should adopt, is yes.

On the CMMC side, NIH sharing requirements can conflict directly with CUI handling restrictions. Research that is jointly funded by NIH and DoD (more common than you might think, particularly in biodefense and health readiness) creates a genuine regulatory conflict. The data needs to be shared under NIH policy and restricted under CMMC. Resolving this requires careful data segmentation and, often, separate processing environments.

The AI Compliance Stack in Practice

When you layer these three frameworks together, the requirements for AI tools become quite specific:

• Data isolation: AI systems must be able to enforce boundaries between FERPA-protected data, CUI, and general research data. Commingling any of these in a shared model context, such as a multi-tenant LLM, is a compliance failure under at least one framework.
• Audit logging: CMMC requires detailed audit trails. FERPA requires disclosure tracking. NIH requires documentation of data handling. The AI tool needs to produce logs that satisfy all three, which means capturing who accessed what data, when, what the AI did with it, and where outputs went.
• Access control: Role-based access is the minimum. CMMC Level 2 requires enforcement of least privilege and separation of duties. An AI tool that gives all project members equal access to all data in the pipeline will not pass assessment.
• Vendor agreements: FERPA requires specific contractual provisions for third-party service providers. CMMC requires flow-down of security requirements to subcontractors and cloud service providers. NIH expects compliance with institutional policies. The AI vendor's terms of service need to satisfy all three sets of requirements simultaneously.
• Output control: If AI-generated outputs are derived from protected data, those outputs inherit restrictions. Universities need mechanisms to classify AI outputs and apply appropriate handling rules automatically, not rely on researchers to do it manually.

Most universities are handling this through a patchwork of IT policies, IRB addenda, and contract-by-contract negotiations with AI vendors. It works until it does not, and the "does not" scenarios tend to surface during audits or, worse, in False Claims Act investigations.

What Actually Needs to Change

The fundamental problem is that universities adopted AI tools designed for general commercial use and are trying to retrofit compliance controls after the fact. The architecture needs to go the other direction: start with the compliance requirements and build the AI capability within those constraints. This means purpose-built environments where data classification, access control, audit logging, and output handling are native features rather than bolt-on configurations.

Institutional leadership, particularly general counsel and CISOs, should be asking their research computing teams a straightforward question: can you show me, right now, how our AI tools enforce FERPA disclosure rules, CMMC access controls, and NIH data sharing documentation simultaneously? If the answer involves a lot of "we have a policy for that," the gap between policy and technical enforcement is where risk lives.

How FirmAdapt Addresses This

FirmAdapt's architecture was built around the premise that compliance controls need to be embedded at the infrastructure level, not layered on top of general-purpose AI. For university research environments, this means data classification and segmentation are enforced before any AI processing occurs, with separate handling pipelines for FERPA-protected records, CUI, and shareable research data. Audit logging meets the granularity requirements of CMMC Level 2 while simultaneously tracking FERPA disclosures and NIH data handling documentation in a unified record.

The platform's access control model supports the role-based and project-based segmentation that multi-framework environments require, so a single institutional deployment can serve multiple research projects with different compliance profiles without commingling data or controls. For institutions navigating the intersection of FERPA, CMMC, and NIH requirements, FirmAdapt provides the technical enforcement layer that makes policy documents actually mean something in practice.