An assessment and an approval are different
GitHub describes an approval assessment in Copilot Code Review and an opt-in path for a formal approval that can count toward merge requirements. The administrator controls where that approval has weight. Preview availability and settings can change, so inspect the live repository controls.
An AI reviewer may share the authoring agent’s blind spots or incomplete context. Treat the assessment as another signal, not as an independent accountable reviewer for high-impact changes.
Start with low-risk file paths
The documented configuration can restrict counted approvals to matching file globs. If a PR touches any file outside the allowed paths, its AI approval should not satisfy the requirement. Begin with a bounded documentation path; verify this behaviour with a mixed-file test PR before relying on it.
Allowed for pilot: docs/**
Test PR A: docs/readme.md only -> inspect whether Copilot approval counts.
Test PR B: docs/readme.md + src/auth.ts -> it must not count under the docs-only scope.Combine independent checks
These are prudent repository policies, not a claim that GitHub imposes them automatically.
- Require relevant automated tests and resolve review conversations.
- Require a code-owner or human review for security, payments, permissions and personal data.
- Dismiss stale approvals or require a fresh review after the diff changes.
- Keep branch protection and merge rights separate from the AI reviewer.
Observe before allowing it to unblock merge
- Enable the assessment or approval capability while leaving its merge weight disabled.
- Collect a few low-risk PRs and compare AI comments with human findings and CI.
- Test allowed and disallowed path patterns, including a PR touching both.
- Only if the signal is reliable for the narrow scope, consider allowing it to count there.
- Record overrides and revisit the scope as files and teams change.