November 9, 2026

AI governance at design time: how to review AI before deployment

Learn how to review AI before deployment: set intake triggers, assign reviewers, record conditions, and verify evidence before a proposal proceeds.

AI governance at design time brings risk review into a decision while the outcome can still change. This guide explains where to start a review, how it connects with discovery and ongoing compliance, and what evidence should be required before a proposed use proceeds.

What is AI governance at design time

AI governance at design time reviews proposed AI uses before design, purchasing, or deployment commitments become difficult to change. It uses specifications, vendor materials, and other evidence to identify risks and define the conditions for proceeding. The same review approach can also support broader data, security, and vendor decisions.

Discovery, compliance workflows, and design-time review contribute different evidence to the same program. Discovery identifies systems and data already present; compliance workflows connect applicable requirements to assessments and controls; early review tests a proposed decision before commitment. A platform can combine these capabilities, and evidence from one should inform the others.

Design time includes a product manager writing a specification, a team choosing a vendor, an acquisition in diligence, or an owner deciding whether to put a model in front of customers. The trigger should be a business milestone that the team can recognize and act on.

What makes a review happen at design time

Set the trigger before a team commits to a design, vendor, or data use. A review scheduled the day before launch is technically pre-deployment, but it may leave no practical opportunity to change the proposal. The test is whether reviewers still have authority and time to influence the decision.

Reconcile discovery findings with reviewed proposals, investigate unreviewed uses, and feed the findings into assessments, remediation tasks, and monitoring. Early review and ongoing oversight should use each other’s evidence.

Early review can begin with a specification, vendor packet, procurement request, contract draft, or diligence material. The source must explain enough about purpose, ownership, data, access, and affected people to support a decision. Ask for missing information before treating the review as complete.

How to put AI governance into product and procurement workflows

Use a recognizable milestone, such as a specification entering design review or a vendor reaching procurement evaluation. Connect that milestone to the following sequence, and assign a person to each handoff.

From AI proposal to an authorized decision

1. Capture the proposal

Required action: Record purpose, owner, affected people, data, permissions, and source version.

Output: A reviewable proposal and missing facts.

2. Screen the use

Required action: Check mandatory assessment triggers and the organization's review policy.

Output: Review path and responsible specialists.

3. Resolve specialist questions

Required action: Evaluate relevant legal, data-protection, security, and operational issues.

Output: Findings and unresolved questions.

4. Set conditions

Required action: Define required changes, owners, due dates, and closure evidence.

Output: An implementation plan tied to the decision.

5. Verify implementation

Required action: Inspect test results, contract terms, configuration, or other required evidence.

Output: Verified conditions and remaining exceptions.

6. Authorize the next step

Required action: Have the designated approver authorize release, signature, or access; record change triggers.

Output: A decision with scope, conditions, and reassessment triggers.

For example, a team evaluating an internal AI search vendor identifies confidential documents as a proposed input. Before contract signature, Legal checks permitted data use, Security tests access isolation, and the business owner records the required restrictions. Contract approval and permission to enable the service remain separate decisions until their conditions are met.

What does design-time governance actually review

AI decisions arise in procurement and business operations as well as product development.

Review products and features from specifications; vendor selection from documentation and terms; partnerships and data sharing from proposed recipients, purposes, and obligations; and acquisitions from diligence materials. Internal tools also need review. Revisit existing AI when a new purpose, data source, permission, or affected population changes its risk. Set the review before the relevant commitment, even when no new code is involved.

What does it cost to find a problem late

A finding can become harder to resolve as implementation and operational dependencies grow. The effect depends on the change; there is no universal cost multiplier.

At proposal stage, a finding may change the planned data flow or vendor terms. During build, it may require implementation changes. Near launch, unresolved conditions can delay release. In production, remediation may involve configuration changes, migration, restrictions, or incident response. Early review preserves more options, but later review can still reduce risk.

For each material finding, record the condition that must change, its owner, and the evidence needed to close it. Measure late findings and resulting rework to understand where an earlier review would have helped your own team.

How does the review get done fast enough to happen early

Reuse existing documents to reduce repeated information gathering. Ask only for missing facts and the confirmations needed to support the decision.

TerraTrue supports document-led intake through Google Docs, Notion, and Confluence. In Confluence, a user starts the review from the page toolbar; supported steps include a launch summary, prefilled intake, and a Risk Scorecard. Initiation and confirmation steps vary by integration. These capabilities sit alongside data protection assessments, EU AI Act assessment workflows, third-party reviews, data discovery, and reporting. Teams can use early review to identify required work and track its completion through the wider governance process.

The useful outcome is a decision with clear conditions. A rating or suggested answer should lead to a verified fact, a question for the owner, or a required control. The Risk Scorecard explains the drivers behind its ratings so reviewers can decide where to investigate first.

Does more automation mean less human judgment

Automation can reduce reconstruction work, but reviewers still verify material findings, challenge unsupported inferences, and resolve exceptions. Evidence and uncertainty should be visible in the review.

TerraTrue’s configurable workflows can route work and mark a review as not needed under defined conditions. The Risk Scorecard supports prioritization; it does not independently approve, close, or route reviews. Define who may authorize each outcome and when a person must intervene.

Frequently asked questions

How does design-time review support compliance?

It identifies applicable requirements while the proposal can still change, assigns required assessments and controls, and preserves the decision record. Implementation evidence and ongoing checks are still needed; an early review alone does not establish compliance.

Does design-time governance replace runtime monitoring?

No. Early review evaluates the proposed use, while monitoring checks deployed behavior and can trigger reassessment. Organizations with systems already in production should improve both according to risk, rather than postponing monitoring until a new review process is complete.

What if the design document does not exist yet?

Review the earliest artifact that contains enough information to assess the proposal: a concept note, vendor packet, procurement request, contract draft, diligence folder, or technical design. If no artifact exists, establish where ownership, purpose, data use, access, and proposed actions will be recorded before the decision advances.

Does this only apply to software features?

No. Vendors, partnerships, acquisitions, data-sharing arrangements, and internal AI use cases all have a design-time moment, and several of them never involve code.

Who owns design-time governance?

Assign questions to the relevant Legal, Security, Governance, Compliance, and business owners, bringing in specialist expertise where needed. Product or the sponsoring team owns implementation, while approval and risk acceptance follow the organization’s authority model.