Google Cloud’s 2026 report, The ROI of AI-assisted Software Development, offers a useful way to understand the difference: AI is an amplifier.

It magnifies what is already present in the engineering system. Strong internal platforms, clear workflows, and mature delivery practices can turn additional development speed into value, while weaknesses in those same areas can become more visible as AI increases the volume of code moving through the SDLC.

That has implications beyond productivity. More AI-assisted code means more code to review, test, secure, approve, and ultimately own. It also introduces questions around which models developers use, what data those models can access, and how organizations demonstrate that the right controls were followed.

This is where AI governance in the SDLC becomes an engineering concern, not just a policy exercise.

Key takeaways

• AI governance in the SDLC defines how organizations control the use of AI across software development without giving up accountability, quality, security, or compliance.

• DORA describes AI as an amplifier of the existing engineering system. Strong foundations can turn additional development velocity into value, while existing weaknesses can become more pronounced.

• Resolute Software’s Six Controls for AI Governance in the SDLC assess six areas: human ownership, model strategy, developer tooling, quality assurance, security and compliance, and data governance.

What is AI governance in the SDLC?

AI governance in the software development lifecycle is the set of responsibilities, technical controls, policies, and evidence used to manage how AI is introduced and used throughout software development.

It isn’t simply an AI policy, nor is it about preventing developers from using AI. The objective is to create enough structure around AI-assisted development that organizations can benefit from additional speed without giving up accountability, quality, security, or control.

Reviews still need to happen, tests still need to run, security requirements still apply, and sensitive data still has boundaries. As AI increases development throughput, those surrounding systems need to keep pace.

What DORA’s AI ROI research tells us about governance

DORA describes a J-Curve of AI value realization, where organizations can experience an initial period of disruption before longer-term value appears. Three factors contribute to that dip: the learning curve as teams adapt their workflows, a verification tax created by reviewing AI-generated output, and pipeline adaptation as testing and approval processes adjust to greater development throughput.

The last two have direct implications for governance. AI can make generating code easier without making accepting that code safely any easier. If additional output accumulates in front of manual security reviews, overloaded reviewers, brittle test suites, or slow approval processes, localized productivity gains can disappear downstream.

DORA also recommends automated, nonoptional security and quality gates capable of handling increased throughput. This makes AI governance more than a compliance concern: the controls surrounding AI-assisted development can influence whether additional engineering velocity translates into sustainable value.

Resolute Software’s Six Controls for AI Governance in the SDLC provide a practical framework for examining that environment. The controls aren’t prescribed by DORA; they come from our work with engineering teams, particularly in regulated environments, where the same governance questions emerge as AI becomes part of development workflows.

Take the AI Governance in the SDLC assessment →

The Six Controls for AI Governance in the SDLC

1. Human ownership and sign-off

AI can draft. Humans still decide.

Every AI-assisted change needs a named person who remains accountable for the result. As the volume of generated output increases, this becomes more important, not less.

DORA’s verification tax highlights the additional review burden created by AI-generated code. AI-assisted changes should therefore pass through the same peer-review expectations as human-written ones, with clear ownership of what ultimately ships.

Ask yourself: If an AI-assisted change caused an incident tomorrow, could you identify who reviewed and approved it?

2. Model strategy and vendor neutrality

The model you standardize on today may not be the model you want next year.

AI capabilities are changing quickly, which makes model choice an architectural decision as much as a procurement decision. DORA notes that significant shifts in AI capabilities are occurring over months rather than years.

A flexible model strategy gives organizations room to respond as capabilities, costs, contractual terms, security requirements, and regulatory expectations change. Vendor neutrality doesn’t mean constantly changing providers; it means avoiding unnecessary lock-in and preserving the ability to move when there is a reason.

Ask yourself: If your primary model provider changed its terms or capabilities tomorrow, how difficult would it be to move?

3. Developer platform and tooling

You can only govern the AI tools you know developers are using.

Organizations need visibility into which coding assistants, IDE integrations, agents, models, and extensions developers actually use, not simply which ones have been officially approved.

DORA identifies strong internal developer platforms as part of the foundation for sustainable AI returns. From a governance perspective, a known and approved AI toolchain also makes it possible to apply internal standards around identity, permissions, repositories, and data access.

Without that visibility, company code, intellectual property, or sensitive context may reach systems the organization hasn’t evaluated.

Ask yourself: Do you know which AI development tools your engineers actually use?

4. Quality assurance for AI-assisted code

More code requires verification capacity that can keep pace with it.

If AI increases development throughput while testing capacity stays unchanged, the bottleneck has simply moved further down the lifecycle. DORA calls this pipeline adaptation and points to automated testing and continuous integration as important capabilities during AI adoption.

AI-assisted code shouldn’t get a lighter quality standard because it was generated faster. The same CI gates should apply, tests should validate behavior, and human reviewers still need to understand whether AI-generated tests meaningfully exercise the code.

Ask yourself: Has your ability to test and verify software grown alongside your ability to generate it?

5. Security and compliance controls

Governance needs to be enforced, not just documented.

Depending on the environment, that can mean access controls, audit logging, secure development gates, approved models, data boundaries, and controls mapped to relevant regulatory requirements.

DORA recommends automated, nonoptional security and quality guardrails to help engineering systems safely absorb increased AI-driven throughput. For regulated organizations, those controls also need to leave evidence that can be produced when required.

Ask yourself: If an auditor asked how AI-assisted development is governed today, what evidence could you produce?

6. Data governance

AI needs useful context, but not every piece of context should reach a model.

DORA argues that AI becomes more valuable when it can access high-quality documentation, clean APIs, and healthy internal data. Poor or outdated internal knowledge can instead contribute to irrelevant output and technical debt.

Governance determines the other side of that equation: what AI should be allowed to access. Source code, customer information, credentials, proprietary documentation, prompts, and logs need clear boundaries, alongside rules for residency, retention, and provider handling of organizational data.

Ask yourself: What company data reaches your AI tools, where does it go, and how long does it remain there?

How mature is your AI governance in the SDLC?

Most organizations already have some of these controls in place. The gaps often appear between them: a policy without technical enforcement, an approved tool configured differently across teams, or an existing review process that hasn’t adapted to increased AI-generated output.

To make those gaps easier to identify, we built the Six Controls for AI Governance in the SDLC into a short assessment. Each area is rated from 1 to 4:

1 — Ad hoc: no shared practice
2 — Emerging: practices exist, but are inconsistent
3 — Defined: documented and mostly followed
4 — Governed: enforced and evidenced

The result is a score out of 24. 20–24 indicates that governance is established across most controls, 13–19 means the pieces are forming, but gaps remain between them, and 6–12 suggests AI adoption is moving ahead of the surrounding governance.

The individual scores matter as much as the total. One weak control can create disproportionate exposure, and disagreement between engineering leaders about how to score an area can reveal governance gaps of its own.

For teams that want to go beyond the score, the full Six Controls playbook (access via the assessment page) takes each area further, with what good looks like for each control and the 2026 data behind the framework. It also includes the scorecard so you can bring the same questions into a wider conversation with your team.

AI governance should help the SDLC keep pace

The goal of AI governance isn’t to put another approval process in front of developers. It’s to build the important controls into the way software is already delivered: clear human ownership, a deliberate model strategy, a governed toolchain, scalable quality gates, enforceable security controls, and clear data boundaries.

DORA’s broader argument is that sustainable AI ROI depends on the engineering system surrounding the technology. AI can amplify development velocity, but that velocity creates value only when the rest of the SDLC can review, test, secure, and govern what is being produced.