What governance does AI-enabled engineering need?

AI-enabled engineering can range from a developer asking for an explanation to an agent changing several repositories and preparing a release. One universal approval process would be too weak for some work and unnecessarily slow for other work.

Useful governance gives teams clear decision boundaries. It allows low-consequence experiments to proceed safely, while requiring stronger assurance where systems, customers or sensitive information could be affected. It should support delivery rather than become a separate committee-driven activity.

Start with accountability and risk

The organisation remains accountable for software delivered with AI. Product owns the problem, value and intended outcome. Engineering owns the technical approach, architecture implications, quality and operability. Security, privacy or risk specialists contribute where the work requires their expertise. An AI tool does not become an accountable role.

Assess each use case by consequence, not novelty alone. Consider data sensitivity, system criticality, reversibility, blast radius, architectural reach, integration complexity, available tests and the amount of judgement required. Also consider what the AI can access, change, execute or publish. A suggestion with no write access creates a different exposure from an agent that can invoke deployment tooling.

Record a named owner and an explicit risk level for material uses. This prevents responsibility from disappearing between the person who requested the work, the team that accepted it and the platform group that enabled the tool.

Set clear boundaries for permitted use

Teams need practical rules covering approved tools, accounts, repositories, data and actions. Define which information may enter a service, how secrets are protected, which external tools or model connections are trusted, and whether generated artefacts require attribution or additional checks. Avoid broad access granted simply to reduce prompts.

Boundaries should distinguish experimentation, routine delivery and sensitive work. A sandboxed prototype using synthetic data may need lightweight approval. Changes to identity, payments, safety-critical behaviour or regulated data require experienced human leadership and stronger evidence. Some activities may remain prohibited until the organisation can control them reliably.

Make the safe path convenient. Provide approved environments, templates, permission profiles and routes for requesting exceptions. If policy is vague or operationally difficult, people are more likely to improvise outside it.

Define evidence and approval points

Governance should specify what evidence is needed before a change advances. That may include peer review, automated tests, security checks, architecture decisions, dependency review, provenance records and successful operation in a controlled environment. The evidence should address the actual failure modes of the change rather than merely prove that a process was followed.

Human approval belongs at consequential decision points: expanding scope, accessing sensitive data, introducing a dependency, changing architecture, merging protected code, deploying to production or accepting residual risk. Lower-risk steps can be automated when controls reliably detect failure and recovery is straightforward.

Keep generation and acceptance meaningfully separate. The same AI output, explanation and generated tests are not independent proof that the change is correct. A responsible person must be able to understand the evidence and decline the result.

Operate governance as a learning system

AI capability, product features and delivery environments change. Review approved uses and controls using evidence from real work: defects, review effort, policy exceptions, security findings, incidents, reversals and operational performance. Include near misses and cases where the tool was stopped, not only successful completions.

Give teams a clear way to report unexpected behaviour and suspend an unsafe workflow. Retain enough traceability to investigate what was requested, which tools and data were used, what changed, who approved it and what reached production. Protect those records according to their sensitivity and retention needs.

Expand authority only when results show that the surrounding engineering system can detect, contain and recover from errors. Tighten or withdraw it when the evidence changes. Proportional governance is therefore a continuous Product and Engineering practice, not a one-off policy document.

Example

A team introduces AI assistance for an internal reporting service. Developers may use an approved assistant with repository context, but customer records and production credentials are excluded. Generated changes follow the normal branch, test and peer-review process.

The team later trials an agent for routine library updates. It works in an isolated environment, can change only one repository and cannot merge or deploy. Dependency, security and regression checks run automatically, while an engineer approves the pull request. After reviewing rework, failures and operational results across several trials, the engineering owner decides whether to extend the agent's scope.

FAQs

• Does every use of AI need formal approval?

  Not necessarily. Organisations can pre-approve low-risk uses within defined tools, data boundaries and engineering controls. Higher-consequence work, exceptions and broader agent authority need explicit review.

• Who owns an error introduced by AI-generated code?

  The organisation and the people responsible for accepting and operating the change retain accountability. The tool's involvement should be traceable, but it does not replace human ownership.

• Should AI engineering governance sit outside normal software governance?

  Usually it should extend existing Product, Engineering, security and operational controls. Separate rules are useful only where AI introduces a distinct risk or capability that existing governance does not address.