AI Code in Regulated Industries: What NIST, CISA, and GDPR Require

The regulations weren’t written for AI coding assistants. They were written for systems and processes that, in most cases, assumed a human reviewed every line of code before it shipped. That assumption is now wrong for a large fraction of the industry, and the compliance gap is real — not because new AI-specific rules appeared, but because existing obligations still apply and the documentation to satisfy them didn’t automatically follow.

BrassCoders, the bug scanner for AI coders, produces one artifact that speaks to this gap directly: a timestamped YAML findings file for every scan. Whether that file satisfies your specific compliance obligation is your compliance team’s call. What this post covers is which obligations exist, what they actually say, and what a team shipping AI-generated code is expected to show an auditor.

The companion research is at /research/ai-code-regulated-industries/ — the four frameworks below with full source links and implementation notes.

What Regulations Actually Require (and What They Don’t Yet Say)

BrassCoders tracks four frameworks that set the current compliance baseline for AI-generated code: NIST AI RMF 1.0, CISA’s Guidelines for Secure AI System Development, GDPR Article 25, and NIST SP 800-218 (SSDF v1.1). None of them explicitly says “run a static analyzer on everything your AI coding assistant writes” — but each one implies it through general principles that predate the AI coding assistant era.

The important framing: these frameworks don’t interpret themselves. “Data protection by design” (Article 25) and “review and analyze human-readable code” (PW.7) are outcomes, not implementation specs. What counts as satisfying the requirement depends on your context, your auditor, and your legal counsel. BrassCoders produces the technical evidence record; the compliance determination is yours.

Teams that have started asking “what does our AI code posture look like to an auditor?” are ahead of the ones that haven’t. The frameworks don’t yet issue specific mandates for AI-coding-assistant output, but auditors are already asking the question.

NIST AI RMF: The US Federal Baseline

BrassCoders treats NIST AI RMF 1.0 — published by the National Institute of Standards and Technology in January 2023 at airc.nist.gov/RMF/1 — as the US federal baseline for responsible AI system governance. The GOVERN function, specifically GOVERN 1.7, requires organizations to document the capabilities, limitations, and known failure modes of AI systems they develop or deploy.

For a team using AI coding assistants to generate production code, the application is direct. The AI assistant has known failure modes: it generates SQL injection sinks, it hardcodes credentials, it produces phantom imports. Documenting those failure modes — as a per-scan findings record tied to each release — is what GOVERN 1.7 calls for in practice. The framework doesn’t mandate a specific scanner. It mandates that the risk be documented.

NIST AI RMF also defines a Map function that requires identifying risks at the use-case level. A team’s AI-coding use case introduces a specific risk profile: code generated without full context of the security constraints, code that passes superficial review because it looks syntactically correct, code that introduces patterns the human reviewer doesn’t immediately recognize as dangerous. The Map function asks organizations to characterize these risks explicitly.

BrassCoders’s YAML findings file is the natural artifact for satisfying both requirements. The timestamped scan output documents what the AI-generated code actually contains (GOVERN 1.7) and evidences the risk identification pass that Map requires. BrassCoders doesn’t interpret the RMF compliance determination — that’s the compliance team’s job — but it produces the technical record the compliance team works from.

CISA’s Guidance on Secure AI Development

BrassCoders treats CISA’s Guidelines for Secure AI System Development as the closest thing to an explicit regulatory requirement for static analysis of AI-generated code. The document, released in November 2023 and co-signed by cybersecurity agencies from the US, UK, Canada, Australia, and New Zealand (the Five Eyes partners), is available at cisa.gov.

The Develop phase section is the directly applicable part. It calls for secure coding practices, testing for vulnerabilities before deployment, and — explicitly — static analysis in the build pipeline. The text addresses AI system development broadly, not just AI-assisted coding, but the requirement applies to AI-generated code the same way it applies to human-written code: the code needs the same secure coding checks regardless of authorship.

This is one of the few regulatory documents that actually names the build pipeline as the point of control. The implication for teams using Copilot, Claude Code, or Cursor to generate code is clear: the AI-generated output needs to pass through a static analysis step in CI before it ships. CISA doesn’t name a specific tool. It names the requirement.

BrassCoders’s CI integrations — the GitHub Actions and GitLab CI setup guides at /blog/add-brasscoders-to-github-actions/ and /blog/add-brasscoders-to-gitlab-ci/ — are the technical implementation of this requirement. The brasscoders scan step in CI, with its output persisted as a build artifact, is what “static analysis in the build pipeline” looks like in practice.

GDPR Article 25 and AI-Generated Code

BrassCoders treats GDPR Article 25 as the legal basis for requiring privacy-safe coding practices from the start of development, not as a post-hoc audit. Article 25, the data protection by design and by default requirement, is published in full at gdpr-info.eu/art-25-gdpr/.

The obligation triggers when code processes EU personal data. It does not matter whether a human or an AI wrote the code. Article 25 requires that technical measures for data protection be implemented from the start — the design phase, not the audit phase. For teams generating code with AI coding assistants, this means the generated code must be reviewed for data-handling issues before it enters the codebase.

BrassCoders’s findings on PII in log statements, unencrypted storage patterns, and hardcoded personal-data strings are the technical input to that review. These aren’t new finding categories invented for GDPR: they’re what the privacy scanner flags on every scan. The compliance team decides whether those findings, addressed before merge, constitute satisfying Article 25’s requirement for their specific deployment context.

Two things are worth separating here. First: the BrassCoders scan itself, run with brasscoders --offline scan, sends zero bytes off the developer’s machine. This satisfies Article 25’s data-minimization requirement for the scanning tool itself — there is no data flow. The tool doesn’t see, transmit, or store personal data. Second: the code under review is a separate question. The findings the scanner produces on that code are the compliance artifact; what the compliance team does with those findings is the compliance determination.

GDPR’s Article 25 has teeth because supervisory authorities have issued enforcement actions against organizations that processed personal data through tools without evaluating the data flows. AI coding assistants that submit code to cloud API endpoints create a data flow worth evaluating. BrassCoders’s offline-by-default design sidesteps that evaluation for the scanner itself. The code the AI generated still needs the privacy review — that’s what the findings file delivers.

The SSDF: Specific Practice References for Auditors

BrassCoders treats NIST SP 800-218 — the Secure Software Development Framework v1.1, published February 2022 and available at csrc.nist.gov/publications/detail/sp/800-218/final — as the practitioner-level implementation standard that gives auditors something specific to cite.

SSDF practice PW.7, Review and/or Analyze Human-Readable Code, requires that organizations use code review and automated analysis to find defects before code ships. The “human-readable code” language applies directly to AI-generated source: the code is code, regardless of who wrote it. PW.7 is the SSDF practice reference a compliance team can point an auditor to; BrassCoders’s scan output is the evidence record showing PW.7 was performed.

PW.7 has two components worth distinguishing. The first is automated analysis — running a static analysis tool against the code. BrassCoders’s 12-scanner stack covers this: Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, detect-secrets, and six custom detectors run on every scan. The second is human review of the findings. BrassCoders produces the YAML findings file for the human (or AI assistant acting as triage layer) to review. Both components of PW.7 map to distinct steps in the BrassCoders workflow.

SSDF is often cited alongside CISA’s Secure AI guidelines because the CISA document references the SSDF by name as the implementation standard for its Secure Development phase requirements. That cross-reference matters for auditors: a team can point to PW.7 as the specific practice underlying the CISA requirement and point to BrassCoders’s findings file as the PW.7 evidence. The chain of evidence is complete.

What BrassCoders Produces as an Evidence Record

BrassCoders writes the scan output as YAML in .brass/ai_instructions.yaml on every run. The structure is stable across scans: a metadata section (scan timestamp, BrassCoders version, scanner versions, project root), a critical_issues array, a findings array sorted by relevance, and a summary section with counts by severity and scanner. Persisted as a CI artifact tied to the commit hash, the file is what an auditor reads to confirm code analysis was performed.

The artifact’s properties matter for compliance purposes. Timestamped: the auditor knows exactly when the scan ran and against what commit. Reproducible: running the same BrassCoders version against the same commit produces the same findings, so the auditor can verify the output independently. Redacted by design: no raw source code, no PII matched values (the privacy scanner redacts before serialization), no secret values (the secrets scanner records type and hash, never the secret itself). The redaction policy means the findings file is safe to retain as a build artifact indefinitely.

The --offline flag enforces zero egress at runtime and returns a non-zero exit code if any network call is attempted. This behavior is auditable: CI logs show the exit code, not an assumption about what the scanner did.

BrassCoders is not a compliance tool in the sense of mapping findings to regulatory control numbers, and it does not interpret regulatory requirements. What it produces is the technical evidence record: timestamped, deterministic, reproducible, redacted. Whether that record satisfies GOVERN 1.7, CISA’s Develop phase requirements, Article 25’s by-design mandate, or PW.7’s analysis requirement — that determination belongs to your compliance team and legal counsel. The scanner’s job is to make the evidence record complete and accurate.

---

Install with one command:

pipx install brasscoders
brasscoders scan /path/to/project

The findings go to .brass/ai_instructions.yaml. Persist that file as a CI artifact tied to the commit hash. The four frameworks above ask, in different ways, that you show an auditor code analysis was performed. The artifact answers that question.

For the full research index on these frameworks — source links, BrassCoders implementation notes, and FAQs for each — see /research/ai-code-regulated-industries/.

Questions about regulated-environment deployment: brass@coppersuncreative.com.