AI Writes the Code. You Own the Risk. Here Is How to Govern It.

The Accountability Gap at the Heart of AI-Assisted Development

When a developer writes a function manually, the organisation owns that code. When an AI development tool — GitHub Copilot, Cursor, Lovable, Replit, Claude Code — generates it, the organisation still owns that code. The tool vendor does not carry liability for what runs in your production environment. Your enterprise does.

That asymmetry is not a contractual technicality. It shapes every compliance audit, every incident response, and every conversation with a regulator. The speed benefit of AI-assisted development is real. But speed without governance creates a category of risk that most enterprise engineering teams have not yet fully accounted for.

This post examines what that risk looks like in practice, where it concentrates, and what a disciplined AI Code Governance approach does to address it.

What AI-Generated Code Actually Looks Like in the Wild

AI development tools are trained on vast corpora of open-source code. They are excellent at pattern completion: given a function signature, a comment, or an adjacent block of logic, they produce plausible, syntactically correct output rapidly. That is genuinely useful.

What these tools do not have is context about your organisation. They do not know your data classification policy. They do not know which fields in your systems carry regulated personal data. They do not know that your security team mandates a specific encryption standard, or that your change management process requires certain metadata to be populated before a record transitions state.

The result is code that looks correct in isolation but may violate organisational standards the moment it touches real data or real workflows. It passes a syntax check. It may even pass a functional test. But it fails the governance layer that separates acceptable code from production-ready code.

Where the Risk Concentrates

Security Anti-Patterns Introduced at Scale

AI tools reproduce the patterns most common in their training data. Where insecure patterns are prevalent in open-source repositories — hardcoded credentials, unvalidated inputs, overly permissive access controls — those patterns appear in generated output. The danger is velocity: a team using AI tooling can introduce more code in a week than it would have written manually in a month. Security anti-patterns scale with output volume.

Platform-Specific Compliance Violations

Enterprise platforms have their own governance layers: field-level security, sharing rules, scoped application boundaries, certified upgrade paths. AI tools generate code without intrinsic awareness of those constraints. A generated script that bypasses an Access Control List, or a class that exposes data outside its intended sharing model, will not announce itself as non-compliant. It will simply run — until an auditor, a penetration test, or an incident surfaces it.

Regulatory Obligations That Fall on the Deployer

The EU AI Act, DORA, the FCA's operational resilience rules, and SOC 2 frameworks all place obligations on the organisation operating the system — not on the tool that helped build it. Under DORA, financial entities must demonstrate that their IT systems meet resilience and change management standards. The source of the code — human or AI — is irrelevant to the regulator. What matters is whether the organisation can evidence control over what runs in production.

Why Existing Controls Fall Short

Most enterprise engineering teams already have controls: code review processes, static analysis tools, CI/CD pipelines with quality gates. The question is whether those controls were designed for the volume and velocity that AI-assisted development introduces.

Traditional code review assumes a human reviewer can meaningfully assess each change. At AI-assisted development velocity, the ratio of generated code to review capacity shifts rapidly. Reviewers begin to approve changes on trust rather than on inspection. The control degrades without anyone formally deciding to reduce it.

Static analysis tools catch known vulnerability patterns. They are less effective at catching organisational policy violations — the kinds of rules specific to your platform configuration, your data model, or your regulatory context. A generic SAST tool does not know that a particular application table contains health data and must never be read without role verification.

The gap is not the absence of controls. It is the absence of controls calibrated to the specific governance requirements of the platform, the organisation, and the regulatory environment in which the code will run.

What AI Code Governance Looks Like in Practice

AI Code Governance is the discipline of applying structured, organisation-specific rules to AI-generated code before it reaches production. It operates at several layers.

Define Your Rule Surface

Start by mapping the rules that matter for your environment. These fall into three categories: security rules (what code must never do), platform rules (what the platform requires or prohibits), and compliance rules (what regulations, certifications, or internal policies demand). This rule surface is specific to your organisation. Generic rulesets are a starting point, not a substitute.

The people who understand data governance, regulatory obligation, and platform architecture are not always the same people who write code. Your rule authorship process must reflect that — making rule definition accessible to domain experts, not reserved for engineers alone.

Apply Rules Continuously, Not at Release

Point-in-time audits are insufficient for AI-assisted development. Rules must be applied continuously — at the point of development, at code commit, and before deployment. Surfacing violations in the developer's working environment, before code enters a review queue, reduces the cost of remediation and prevents the accumulation of technical and compliance debt.

Establish Quality Gates That Reflect Governance Requirements

Quality Gates in a deployment pipeline should encode governance requirements, not just functional test pass rates. A deployment that passes all unit tests but violates a data access policy is not ready for production. The gate logic must reflect the full definition of production-readiness for your environment — security, compliance, and platform standards together.

Maintain an Evidence Trail

Regulators and auditors require evidence that controls operated as designed. A full scan run against a codebase before a major release, with results documented and retained, provides that evidence. It demonstrates that governance was applied systematically, not selectively. This is particularly relevant under DORA and FCA operational resilience frameworks, where firms must show ongoing assurance over IT change processes.

The Practical Implication for Engineering Leaders

If your organisation is using AI development tools — and most are, formally or informally — the question is not whether to govern AI-generated code. The question is whether your current governance posture was designed for the volume, velocity, and specificity that AI-assisted development demands.

Existing controls may be sufficient. More often, they need calibration: more platform-specific rules, tighter integration into developer workflows, and a clearer audit trail for regulators. The work of AI Code Governance is making existing governance intent operational at the pace AI tools create.

AI writes the code. Your organisation owns what happens next. Production-Ready AI Code requires that the gap between generation and governance be closed deliberately — not left to chance or to tools that were never designed to close it.

Frequently Asked Questions