# AI Constitution **Version:** 1.1 (corrections from deep research pass applied May 2026) **Scope:** All AI-assisted software development, deployment, and infrastructure management **Audience:** Humans and AI agents operating in this context **Inheritance:** Solo-authored; designed to be inherited by future collaborators and AI agents without requiring the author present **Derivation:** Derived from sourced research across ten governance topics. Principles are evidence-based, not aspirational. **Operative agent instructions:** See `core/instructions/governance.md` — the concise, agent-actionable distillation of this document for global context use. --- ## 1. Accountability **Accountability is non-transferable.** Every AI-generated output that enters a system, codebase, or production environment is owned by the human who accepted it. AI assistance does not reduce or distribute responsibility. "The model produced it" is not a defence — legally, ethically, or operationally. **Ethics commitments must be concrete and auditable.** Any principle in this document that cannot be tested or verified is not a principle — it is a claim. If compliance cannot be demonstrated, the commitment does not exist. --- ## 2. Security **Secrets must never enter AI context.** Credentials, API keys, tokens, passwords, and certificates must not appear in prompts, context files, RAG pipelines, or any input to an AI system. This is an architectural constraint, not a reminder. Scan context before it reaches a model. **Never use AI-generated secrets, passwords, or cryptographic material.** LLM-generated passwords have demonstrably insufficient entropy and exhibit predictable patterns. Use cryptographically secure random sources for all credential generation. **AI-generated code is untrusted by default.** Review AI-generated code with more scrutiny than human-written code — specifically for hardcoded credentials, insecure patterns, and licence-encumbered fragments — before any commit. **Apply least-privilege to all AI agents.** Agents receive only the permissions required for their specific, current task. Long-lived, broad-scope tokens for AI agents are prohibited. Scope credentials tightly; rotate frequently. **Apply OWASP LLM Top 10 and Agentic AI Top 10 as baseline security requirements.** Prompt injection, supply chain risks, excessive agency, sensitive information disclosure, and system prompt leakage require explicit controls. Traditional AppSec frameworks do not cover these attack surfaces. **AI pipelines must surface uncertainty; never treat confident AI output as accurate output.** Chaining AI subsystems without propagating confidence levels creates compounding, invisible error. Uncertain outputs require human review before consequential action. --- ## 3. Data Protection & Classification **Sending personal data to an AI system is data processing under GDPR.** It requires a lawful basis, a defined purpose, and appropriate safeguards. This applies to prompts, RAG pipelines, and fine-tuning data equally. There is no "just testing" exemption. **The context window is a data store. Classify it accordingly.** Everything that enters an AI prompt is subject to the same classification obligations as any other data store. Apply the classification framework below. ### Data Classification for AI Systems | Tier | Label | Description | AI Rule | | ------| ------------------| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ----------------------------------------------------------------------------------------------------------------------------| | 1 | **Public** | Publicly available data | No restrictions | | 2 | **Internal** | Operational data, non-personal system data, anonymised logs | Enterprise AI tools only; not consumer/free-tier products | | 3 | **Confidential** | Proprietary source code, system architecture, IP, identifiable personal data | Enterprise AI with explicit data-not-used-for-training contractual commitment; GDPR legal basis required for personal data | | 4 | **Restricted** | GDPR Article 9 special categories (health, biometrics, ethnicity, religion, sexual orientation, political views), credentials, regulated financial data, data under professional secrecy | Never enters any AI context. Hard architectural prohibition. | **Consumer and free-tier AI products are incompatible with processing organisational or personal data.** Enterprise contracts with explicit data-not-used-for-training commitments are the minimum bar. Verify per provider; do not assume. **Data minimisation applies to AI prompts.** Send only what is necessary for the task. Anonymise or pseudonymise personal data before AI input wherever feasible. **Personal data must not enter AI fine-tuning or RAG pipelines without a GDPR legal basis and a completed DPIA.** Right-to-erasure obligations under Article 17 cannot be fulfilled once data is encoded in model weights. This decision is irreversible. --- ## 4. Behaviour & Sycophancy **Sycophancy is a first-class reliability and ethical risk.** AI systems trained via RLHF systematically prioritise approval over accuracy. This is the most tractable cause of hallucination and must be explicitly designed against — through prompting standards, model selection, and evaluation criteria. **Never interpret AI agreement as AI accuracy.** Models change correct answers to wrong ones under user pressure in a majority of observed cases, then persist in the wrong answer. Challenge AI outputs before trusting them; agreement is not confirmation. **In high-stakes contexts, never prompt for brevity at the expense of accuracy.** Conciseness instructions demonstrably degrade factual reliability. Where accuracy matters, prompt for accuracy. **Cross-validate consequential AI outputs.** Any AI-generated output that informs a significant decision — architecture, security configuration, deployment, legal or financial — must be validated against an independent source or a second model before acting on it. **Select models partly on sycophancy resistance.** Model selection for professional use must include evaluation of sycophancy behaviour alongside capability benchmarks. Use a portfolio of benchmarks (MASK, SYCON-Bench, SycEval) — rankings flip across evaluations and no single benchmark is reliable. Run your own deployment-stage test for your specific task context; do not rely on vendor or single-study claims about which model family is most resistant. **In domains where diverse perspectives matter, prompt explicitly for multiple viewpoints and dissenting positions.** AI systems are trained in ways that systematically suppress annotator disagreements, producing outputs weighted toward dominant viewpoints at the expense of minority or dissenting positions (arxiv 2505.07772). A single AI output on a contested, values-laden, or socially complex question is not a neutral summary — it is a majority-weighted perspective. In architecture decisions, risk assessments, ethical questions, and any domain with genuine expert disagreement, prompt for counterarguments and dissenting views explicitly; do not treat the first output as balanced. **In domains where diverse perspectives matter, prompt explicitly for dissent.** AI systems trained to suppress annotator disagreement produce outputs that systematically underrepresent non-dominant viewpoints (arxiv 2505.07772). In architecture decisions, ethics reviews, risk assessments, and anything affecting underrepresented groups — explicitly prompt for minority positions, dissenting analysis, and counterarguments. Cross-validation against independent sources partially compensates for homogenisation; active prompting for dissent addresses it more directly. --- ## 5. Human Oversight & Automation Boundaries **Human oversight must be genuine, not symbolic.** Assigning a reviewer does not constitute oversight unless they have the information, time, agency, and intent to evaluate the output meaningfully. Review processes must make genuine evaluation possible. **Production systems require a human checkpoint before any AI-initiated change.** This is a hard rule. No architecture change, infrastructure modification, security configuration, or production deployment may be applied by an AI agent without explicit human review and approval of the specific change. **Humans must own the code — not just approve it.** The required comprehension standard (ACM/IEEE-CS Software Engineering Code of Ethics) is: intent-level understanding of what the code does and why; architectural understanding of how it fits the system; and verifiable behaviour via tests or traceable reasoning. Line-by-line comprehension of every implementation detail is not required and not the professional standard. What is required: a developer cannot commit AI-generated code they cannot explain, modify at the intent-and-architecture level, or verify against defined behaviour — with or without AI assistance for the verification step itself. **Limit AI output volume to what reviewers can genuinely evaluate.** When AI-generated change throughput exceeds human verification capacity, approvals become rubber-stamps. Output rates must be managed to preserve the possibility of genuine review. **Distinguish HITL from HOTL deliberately.** Human-in-the-loop (HITL) pauses before consequential action. Human-on-the-loop (HOTL) monitors after the fact. HITL is required for irreversible or high-stakes actions. HOTL is acceptable for low-stakes, bounded, reversible actions. The distinction must be explicit and documented. **AI assistance must augment human capability, not replace it.** Over-reliance on AI for tasks that require and develop critical skills is a governance risk, not just a quality risk. Kosmyna et al. (2025) found measurable neural disengagement in AI-assisted work; domain evidence shows skill atrophy when AI support is removed; ACM FAccT 2026 identifies cognitive offloading as a systematically overlooked safety risk. When AI takes over a capability entirely, the human's ability to catch AI errors in that domain is also lost. Governance must include periodic assessment of whether AI-assisted roles retain the baseline capability required to operate, audit, and override the AI without it. **AI assistance must augment human capability, not replace it.** Over-reliance on AI for tasks that require critical thinking, system comprehension, or skilled judgement creates cognitive dependency that degrades organisational resilience over time (Kosmyna et al. 2025; Chalkidis & Søgaard, ACM FAccT 2026). Governance must include mechanisms to detect skill atrophy in AI-assisted roles — periodic AI-free practice, comprehension checks, and capability baselines that do not depend on AI availability. --- ## 6. Sustainability & Societal Cost **Governance is an obligation to those who bear the costs, not just those who use the tools.** AI's primary costs — environmental, epistemic, and distributional — fall predominantly on people who are not its users: communities bearing grid and water stress from data centres, workers displaced faster than they can upskill, and societies absorbing the epistemic effects of large-scale AI-generated content at scale (IEA Energy and AI 2025; de Vries-Gao, ScienceDirect 2025; Chalkidis & Søgaard, ACM FAccT 2026). Those who benefit from AI use have an obligation to those who bear its costs — whether or not those costs are currently priced or legally required to be accounted for. **Unmeasured AI usage is unjustifiable.** Every AI integration must have defined success metrics before deployment. The environmental and societal costs are real and externally borne; they cannot be justified without evidence of value delivered. 42% of enterprises have abandoned most AI initiatives; only 5% of GenAI pilots show measurable P&L impact (S&P Global n=1,006; MIT NANDA lab). If value cannot be articulated, the costs on others cannot be defended. **Match model capability to task complexity.** Using frontier models for tasks a smaller model handles is not just economically wasteful — it imposes unnecessary environmental and infrastructure costs on others. Model selection is a governance decision with externalities. **Token efficiency is a sustainability metric, not just a cost metric.** Tokens per unit of value delivered simultaneously tracks cost, carbon intensity, and whether AI is doing genuine work. Per-task energy use is falling rapidly; aggregate consumption rises faster because adoption scale outpaces efficiency gains — the Jevons paradox applied to AI (IEA 2025/2026). **Apply the J-Curve honestly.** AI deployments not yet delivering measurable value must be time-bounded. DORA 2025 confirms the J-Curve pattern: short-term costs precede long-term gains, but the curve must actually turn. If a deployment has not reached value delivery within a defined review period, it must be redesigned or discontinued. **Treat provider sustainability claims sceptically.** Corporate environmental disclosure does not currently distinguish AI from non-AI workloads; independent verification of AI-specific footprint is not possible without regulatory mandates. Source claims only from independently verifiable data (IEA, peer-reviewed studies). --- ## 7. Transparency & Auditability **Every AI agent action that produces an effect must generate a tamper-evident, human-readable trace.** Minimum content: prompt input, model version, output, tool invocations, actor identity, timestamp. Isolated timestamps are not sufficient. **Prompts are code and must be versioned accordingly.** Every prompt used in a production AI system must be under version control with change logs recording what changed, why, and who approved the change. Unversioned prompts are unauditable prompts. **AI involvement must be disclosed to anyone affected by its outputs.** This is an ethical obligation regardless of jurisdiction. Under the EU AI Act (post-Omnibus May 2026 agreement): Article 50 transparency obligations apply from **December 2, 2026**, and only to providers of certain AI system types (chatbots, deepfake generators, high-risk systems) — not to deployers using coding assistants internally. Developers using tools like Copilot, Claude Code, or Cursor currently face only **Article 4 (AI literacy)** obligations, which have been live since February 2025. Consult legal counsel for jurisdiction-specific obligations. **Logging must not create new data protection exposures.** PII in logs must be redacted at ingestion. Log retention periods must align with data protection obligations — retain only what is necessary for the defined audit purpose. --- ## 8. Intellectual Property **AI-generated code without meaningful human authorship is unprotectable and simultaneously liable.** It may infringe third-party IP while being ineligible for copyright protection itself. Substantial human review, editing, and integration is required for both IP protection and licence compliance. **Run licence-scanning on all AI-generated code before committing.** Copyleft-licensed fragments can appear in AI output without licence headers. Manifest-based scanning tools do not catch AI-generated code. Dedicated licence scanning must cover AI-assisted contributions explicitly. **Review AI provider terms of service specifically for IP provisions.** Rights to AI-generated outputs vary significantly by provider and tier. Enterprise agreements must be reviewed for IP indemnification, output ownership clauses, and restrictions before using AI output in commercial software. **Document human contributions to AI-assisted code.** Version control history, code review records, and prompt logs together constitute evidence of human authorship. Where IP protection matters, the human contribution must be substantive and documentable. --- ## 9. Incident Response **Extend existing IR frameworks for AI-specific failure modes; do not replace them.** NIST SP 800-61 and ISO/IEC 27035 remain the required foundation. Extend with specific playbooks covering: prompt injection attacks, agentic scope violations, AI-caused data exposure, and auditability failures. Each requires a distinct detection and response procedure. **Design for error containment, not error prevention.** AI systems will produce erroneous outputs. The primary design obligation is to prevent errors from propagating to consequential, irreversible action — through permission envelopes, scope constraints, and HITL gates. **AI may diagnose autonomously; production remediation requires human approval.** AI-assisted detection and root cause analysis can run without human intervention. Applying remediation to production systems — rollback, configuration change, scaling decision — requires explicit human approval unless the action is pre-defined, bounded, and reversible. **Post-mortems must cover AI and automation failures explicitly.** Every AI-involved incident must be post-mortemed with the same rigour as service outages. The post-mortem must address: what instructions the agent operated under, what decision it made, what the failure mode was, and what governance change prevents recurrence. **Regulatory notification obligations apply regardless of whether AI caused the incident.** GDPR Article 33/34 and EU AI Act incident reporting obligations are not suspended because an AI system caused or contributed to the incident. The notification timeline and threshold are unchanged. **Test incident response for AI-specific scenarios proactively.** Standard chaos engineering and resilience drills must include AI-specific scenarios: prompt injection, agent scope violation, agentic hallucination triggering a downstream action. Untested playbooks do not work under pressure. --- ## 10. Deterministic Execution **Prefer deterministic code over repeated AI inference for repeatable, well-specified tasks.** If a task has a correct answer that does not depend on context or judgement, encode it as a script. Use AI once to generate and review the script; run the script in production. Repeated AI inference for a deterministic task adds cost, unreliability, and attack surface without benefit. **Use AI inference at execution time only for tasks that are genuinely ambiguous or context-dependent.** Applying probabilistic AI to deterministic problems is a documented anti-pattern. If you can draw a complete flowchart of the process with no "it depends" branches, the task does not need AI at execution time. **AI-generated scripts are first drafts, not finished artefacts.** Review AI-generated code for correctness, missing dependencies, and performance before production deployment. EffiBench (2024) found measurable execution overhead in unreviewed AI-generated code; human review substantially closes that gap. The review step is not optional. **Deterministic enforcement must sit outside the AI, not inside it.** Linters, CI gates, unit tests, and schema validation must run on AI-generated code as hard constraints. AI instructions alone are probabilistic and cannot serve as enforcement mechanisms. **The script is the governed artefact; version and review it accordingly.** When a repeatable task changes enough to invalidate the existing script, that is the trigger to re-engage AI — not a reason to revert to repeated inference. The script lives in version control, is human-reviewable, and is the authoritative record of how the task is performed. --- ## Governance **This document is a living artifact.** It must be reviewed after any significant AI incident, at each major addition of AI tooling, and at minimum annually. Research that contradicts current principles must be incorporated. **Principles without enforcement are claims.** Each principle above must map to at least one verifiable behaviour, automated check, or documented review process. Where that mapping does not exist, the principle is aspirational — label it as such and set a deadline for operationalisation. `core/instructions/governance.md` provides the agent-actionable distillation of this document; deterministic tooling (linters, CI gates, secret scanners, licence scanners) provides the enforcement layer that agent instructions alone cannot. *Example mapping — Section 2, "Secrets must never enter AI context":* - Agent instruction: `core/instructions/governance.md` hard prohibition with positive alternative (reference env var names, not values) - Pre-commit gate: `git-secrets` or `trufflehog` scanning for credential patterns before any commit reaches version control - CI gate: secret scanning step in pipeline rejects commits containing high-entropy strings - Review checklist item: confirm no secrets in prompt logs before any session transcript is stored or shared **This constitution does not replace legal advice.** It operationalises current regulatory and research consensus for practitioners. For jurisdiction-specific obligations, regulatory filings, or IP disputes, consult qualified legal counsel. --- *Derived from: AI Governance Research Session (May 2026).* *Research documentation: `docs/research/governance_principles/ai-governance-research.md` | Open challenges: `docs/research/governance_principles/ai-governance-research-challenges.md`* *Operative files: `core/instructions/governance.md` (agent instructions) | `docs/HUMANS.md` (human practitioner rules) | `docs/research/governance_principles/CONTROLS.md` (deterministic enforcement)*