SENAR Reference: Governance and Compliance Annex

This annex maps SENAR practices to governance, regulatory, and compliance requirements for organizations using AI-native development teams. It is intended for compliance officers, auditors, legal counsel, and engineering leadership evaluating SENAR adoption in regulated environments.

Disclaimer: This document provides recommended practices and compliance mapping guidance. It does not constitute legal advice. Organizations should consult qualified legal counsel for jurisdiction-specific regulatory interpretation.

A. Responsibility Model

A.1 The Accountability Principle

In SENAR, the Supervisor is accountable for all AI output they approve. This is not a delegation of responsibility to the AI agent — it is an explicit acceptance of responsibility by the human who directs, reviews, and approves the work.

The accountability chain follows a clear principle:

AI generates. Human approves. Human is responsible.

This principle is embedded structurally in SENAR through Quality Gates. When a Supervisor passes a Task through QG-2 (Implementation Gate), they are attesting that:

• CI passes, tests pass, types are clean (automated verification);
• Acceptance criteria are satisfied (human judgment);
• No security vulnerabilities were detected (tooling-assisted);
• The output is fit for its intended purpose (professional judgment).

This attestation is the compliance-relevant act. It is recorded, timestamped, and attributable to a specific individual.

A.2 Responsibility by Quality Gate

Each gate passage constitutes a documented approval decision by an identified human.

A.3 Gate Bypass Responsibility

SENAR Standard Section 8.6(c) requires that Gate Bypasses include justification, risk assessment, remediation plan, and senior approval. From a compliance perspective:

• The person who approves the bypass owns the risk for any downstream consequences.
• Gate Bypass records SHALL be preserved as audit evidence.
• Organizations SHOULD track Gate Bypass rate (Standard 8.6(d)) as a compliance health metric.
• Auditors should treat elevated Gate Bypass rates as an indicator of process pressure that warrants investigation.

A.4 Escalation Paths

A.5 Shared Responsibility in Team+ Configurations

In Team+ configurations, responsibility is distributed across dedicated roles:

• Context Architect is responsible for requirement quality and traceability completeness.
• Knowledge Engineer is responsible for knowledge base accuracy and freshness.
• Flow Manager is responsible for process adherence and metric collection.
• Verification Engineer is responsible for independent verification and Quality Sweep thoroughness.
• Supervisor remains responsible for the specific AI output they direct and approve.

This distribution does not dilute individual accountability — it creates a chain of documented responsibilities, each with its own audit trail.

B. Audit Trail Requirements

B.1 SENAR Artifacts as Audit Evidence

SENAR’s structure produces the following artifacts, each of which constitutes audit evidence:

B.2 Quality Gate to Audit Evidence Mapping

B.3 Demonstrating Adequate Supervision

An auditor evaluating whether AI-generated code was adequately supervised should examine:

1. Task definition quality. Was QG-0 enforced? Did the Task have clear, verifiable acceptance criteria before AI work began? A well-defined Task demonstrates intentional direction, not open-ended AI generation.

2. Gate passage records. Did QG-2 pass with documented Supervisor approval? Were automated checks (CI, tests, lint, security scan) executed and recorded? Automated gate records are stronger evidence than manual checklists.

3. Risk-appropriate review. Was the risk level correctly classified? Did high-risk changes receive peer review as required by Standard 8.7? Consistent application of risk-based review is a key indicator.

4. Session discipline. Were Sessions bounded in duration? Were checkpoints performed at the required cadence? Unbounded sessions without checkpoints suggest inadequate attention.

5. Knowledge capture. Were decisions documented? Were Dead Ends recorded? Active knowledge capture indicates reflective supervision, not passive acceptance.

6. Metrics trend. Is the Defect Escape Rate stable or improving? A rising DER suggests degrading supervision quality.

7. Gate Bypass rate. Are bypasses rare and well-justified? Frequent bypasses indicate systemic process issues.

B.4 Retention Recommendations

C. Regulatory Mapping

C.1 ISO 9001:2015 — Quality Management Systems

C.2 SOC 2 Type II — Trust Services Criteria

C.3 GDPR — Considerations for AI Tools Processing Personal Data

GDPR applies when AI coding tools process personal data. This can occur when:

• Source code contains personal data (e.g., test fixtures with real user data, hardcoded credentials);
• AI prompts include personal data from production systems (e.g., debugging with real data);
• AI tool providers process and potentially retain prompt data;
• Session logs contain personal data referenced during development.

C.4 General Software Audit Requirements

C.5 EU AI Act (Regulation 2024/1689)

AI coding assistants typically fall under ‘limited risk’ or ‘general-purpose AI’ categories. Key obligations:

• Article 50: Transparency — users must be informed they interact with AI. SENAR’s explicit labeling of AI-generated work satisfies this.
• Article 53: Obligations for GPAI model providers — relevant when organizations fine-tune or deploy models.
• Organizations operating in the EU SHOULD review their AI tool usage against the Act’s requirements and maintain documentation of compliance measures.

C.6 NIST AI Risk Management Framework (AI RMF 1.0)

SENAR practices align with NIST AI RMF functions:

• Govern: Roles (Section 4), Governance (this annex)
• Map: Risk-based review tiers (Section 8.7), Data classification (D.1)
• Measure: Metrics (Section 9), Quality Sweeps (Section 7.4)
• Manage: Quality Gates (Section 8), Incident Response (F.1)

Organizations subject to US federal AI governance requirements SHOULD document this mapping.

C.7 ISO/IEC 27001:2022

SENAR controls map to ISO 27001 Annex A:

• A.8.25 (Secure development lifecycle): Quality Gates, Verification Checklist
• A.8.28 (Secure coding): Rules 10.6, 10.15, AI Output Review
• A.8.9 (Configuration management): Rules 10.13, 10.14
• A.5.12 (Classification of information): Data classification (D.1)
• A.8.15 (Logging): Audit trail requirements (B.1)

Organizations seeking ISO 27001 certification SHOULD map SENAR artifacts to their Statement of Applicability.

D. Data Governance for AI Tools

D.1 Data Classification for AI Interactions

Before sending any data to an AI coding tool, organizations should classify that data and apply appropriate controls:

D.2 AI Tool Selection Criteria

Organizations should evaluate AI coding tools against the following criteria, weighted by their data classification requirements:

D.3 On-Premise vs. Cloud AI: Decision Framework

Organizations operating in regulated industries (finance, healthcare, government, defense) should default to on-premise AI tools for all non-public data unless a specific risk assessment justifies cloud use.

D.4 Data Retention for AI Interactions

D.5 Right to Deletion

A critical question for organizations subject to GDPR or similar privacy regulations: if personal data was included in an AI prompt, can its influence be removed from the model?

Current reality: For cloud-hosted AI models, organizations generally cannot guarantee removal of training influence from model weights, even if the provider deletes stored prompt data. This is a fundamental limitation of current large language model architectures.

Recommended practices:

1. Prevent rather than remediate. Data classification and QG-0 context preparation should exclude personal data from AI prompts. Prevention is more reliable than post-hoc deletion.
2. Contractual no-training clauses. Ensure AI tool contracts explicitly exclude customer data from model training.
3. Prompt data deletion. Ensure contracts include prompt data deletion obligations and verify compliance.
4. On-premise models for restricted data. When deletion guarantees are required, use on-premise models where the organization controls the full data lifecycle.
5. Document the limitation. If an organization cannot guarantee deletion of training influence, document this as a known risk in the DPIA and apply compensating controls (data minimization, synthetic data).

E. Intellectual Property and Licensing

Note: AI-generated code IP is an evolving legal landscape with significant jurisdictional variation. The following represents recommended practices as of the time of writing. Organizations should obtain qualified legal counsel for their specific jurisdiction.

E.1 Ownership of AI-Generated Code

The legal status of AI-generated code ownership varies by jurisdiction and remains unsettled in many:

Recommended practices:

1. Update employment and contractor agreements to explicitly address AI-assisted and AI-generated code.
2. Review AI tool provider terms to confirm output ownership assignment.
3. Document human creative contribution through SENAR’s Task records (goal, acceptance criteria, architectural decisions, Supervisor review notes). This documentation strengthens authorship claims.
4. Maintain records of Supervisor direction — the context provided to the AI, the selection and modification of AI output, and the judgment applied during review.

E.2 License Contamination Risk

AI models trained on open-source code may generate output that reproduces or closely resembles code under copyleft licenses (GPL, AGPL, LGPL). If such output is incorporated into proprietary software without compliance, this creates license contamination risk.

Risk factors:

• AI models trained on public code repositories without license filtering;
• Generated code that closely matches existing open-source implementations;
• Insufficient review of generated code for license-encumbered patterns.

Recommended practices:

1. Automated license scanning. Include license scanning tools in the CI pipeline (enforced at QG-2). Scan both direct dependencies and generated code for known license-encumbered patterns.
2. Dependency audit at QG-3. For Team+ configurations, include dependency license audit in the QG-3 verification scope.
3. Quality Sweep coverage. Include license compliance in Quality Sweep scope (dependency health audit).
4. AI tool selection. Evaluate AI tool providers’ training data policies and any indemnification they offer against IP claims.
5. Code provenance documentation. For high-value or high-risk code, document whether it was AI-generated, human-written, or a combination.

E.3 Documentation Requirements for IP Compliance

Organizations seeking to demonstrate IP compliance for AI-generated code should maintain:

F. Incident Response for AI-Generated Defects

F.1 Response Process

When a production incident is traced to AI-generated code, the following process applies in addition to the organization’s standard incident response:

1. Triage and contain. Standard incident response: assess severity, contain impact, restore service.

2. Trace the origin. Use SENAR’s traceability chain:

   • Production incident → code change (version control);
   • Code change → Task record (commit references Task);
   • Task record → requirement (QG-0 requirement link);
   • Task record → Supervisor (Task assignment and QG-2 approval);
   • Task record → Session (session log with timestamps and context).

3. Assess gate effectiveness. For each Quality Gate the defective code passed through:

   • Did the gate execute? (Check gate records.)
   • Did automated checks pass? (Were checks adequate for this defect type?)
   • Did human review occur? (Was it risk-appropriate per Standard 8.7?)
   • Was a Gate Bypass involved? (If so, was the bypass risk assessment accurate?)

4. Classify the root cause. Use the AI-specific root cause taxonomy (Section F.2).

5. Remediate. Fix the immediate defect. Create a Task for any systemic improvement.

6. Credential rotation. If credentials or secrets are exposed (committed to VCS, included in AI context, or logged), the organization SHALL rotate affected credentials within 24 hours and audit access logs for unauthorized use.

7. Post-incident review. Conduct a structured review addressing:

   • Was supervision adequate for the risk level of this change?
   • Were Quality Gates effective? Should gate criteria be strengthened?
   • Was the AI agent’s context sufficient? Should knowledge entries be created?
   • Should the risk classification for this type of change be elevated?

Organizations SHOULD define severity-based response timeframes for AI-generated vulnerabilities. Recommended: Critical — 4 hours, High — 24 hours, Medium — 72 hours, Low — next increment.

F.2 AI-Specific Root Cause Taxonomy

Standard root cause categories (logic error, integration error, performance issue) apply to AI-generated code. The following additional categories are specific to AI-native development:

F.3 Traceability Chain

The complete traceability chain for incident investigation:

Production Incident
  └─► Code Change (commit hash, diff, timestamp)
        └─► Task Record (goal, AC, work type, Supervisor)
              ├─► Requirement (Story / business requirement)
              ├─► QG-0 Record (context quality at task start)
              ├─► QG-2 Record (implementation verification)
              │     ├─► Automated check results (CI, tests, lint, security)
              │     └─► Supervisor approval (who, when)
              ├─► QG-3 Record (if applicable: review, acceptance tests)
              ├─► Session Log (when, duration, checkpoints, context)
              └─► Knowledge Entries (decisions, Dead Ends, patterns)

This chain enables auditors and incident investigators to reconstruct the full decision history from business requirement through implementation to production deployment.

G. What SENAR Does Not Cover

SENAR is a process methodology for supervised AI-native development. The following compliance-relevant areas are outside SENAR’s scope and require additional organizational controls:

Organizations adopting SENAR should integrate it into their broader governance, risk, and compliance (GRC) framework rather than treating it as a standalone compliance solution.

G.1 Compensating Controls for Core/Foundation Configuration

SENAR’s Core configuration (1 Pair) and Foundation configuration (1–3 Pairs) combine multiple responsibilities in fewer people. This creates a segregation-of-duties gap that may concern auditors:

Organizations in regulated industries operating at Core or Foundation scale should document these compensating controls and assess whether they are adequate for their regulatory obligations. Transitioning to Team configuration may be necessary to satisfy segregation-of-duties requirements.

H. Implementation Checklist

Organizations adopting SENAR in a regulated environment should address the following:

• Establish data classification policy for AI tool interactions (Section D.1)
• Evaluate and select AI tools based on data classification and compliance requirements (Section D.2)
• Execute data processing agreements with cloud AI tool providers (Section D.3)
• Update employment and contractor IP agreements for AI-generated code (Section E.1)
• Integrate license scanning into CI pipeline at QG-2 (Section E.2)
• Configure Quality Gate automation to produce audit-grade records (Section B.1)
• Establish Gate Bypass approval process with documentation requirements (Section A.3)
• Define data retention policies for SENAR artifacts (Section B.4)
• Conduct DPIA if AI tools will process personal data (Section C.3)
• Document compensating controls if operating at Core/Foundation configuration (Section G.1)
• Establish AI-specific root cause categories in incident management process (Section F.2)
• Include AI tool compliance in Quality Sweep scope (Section D, E)
• Train Supervisors on data classification and AI-specific compliance obligations
• Integrate SENAR audit trail into existing GRC tooling and reporting