Who Owns Database Changes When AI Writes Migrations?

Who Owns Database Changes When AI Writes Migrations?

AI can write a database migration. I still need a named human to own the risk. Before deployment, I require 2 separate approvals: the technical lead confirms readiness, and the client or authorized stakeholder approves the release.

I use these checks to keep responsibility clear:

• Name each owner. Assign scope, implementation, review, testing, and deployment to specific roles.
• Keep proof in one record. Link the reviewed change, test results, approvals, and deployment logs.
• Approve each stage. Separate expansion, backfill, cutover, and destructive cleanup.
• Test the fallback. Rolling back application code does not restore deleted data.
• Plan for failure. Name a human incident commander and backup, set stop conditions, and verify recovery before closing the incident.

At Appeneure, agents handle assigned tasks while Satya Prakash Goyal owns final technical readiness. My rule for any team is the same: <u>approval applies to the exact change reviewed</u>. If that change shifts, review, testing, and release approval must happen again.

Define Roles and Human Approval Authority

PM and Builder: Set Scope and Write the Migration

After naming owners, give each role a specific task and a human approval checkpoint. The PM agent records scope, acceptance criteria, and dependencies. The Builder implements the migration and related application code, then provides evidence of the work.

Reviewer, QA, and DevOps: Check, Test, and Execute

The Reviewer checks implementation quality. QA then verifies the results against the acceptance criteria.

DevOps runs only approved changes. Its system checks help verify the work, but they don’t replace the technical lead’s review of the evidence. That evidence feeds into the final readiness check.

Technical Lead and Client: Separate Technical Readiness from Business Approval

Technical sign-off and business approval are separate decisions. The technical lead handles technical risk and performs the final review of complex integrations. The client or authorized human stakeholder approves business scope and final milestone acceptance. Any decision affecting scope, cost, product behavior, or the client relationship must go back to a human.

Use the matrix below to separate work, verification, and final authority. Assign a named person to each human authority role.

sbb-itb-622dc24

AI-accelerated migrations at scale | Charles Covey-Brandt | StaffPlus New York 2025

Require Proof at Each Deployment Gate

Once ownership is assigned, require proof at every gate. AI can draft the change; humans must prove it is safe.

Keep one migration record linking the approved issue, design review, pull request, CI, staging tests, approvals, production log, and post-deploy checks. Every handoff needs evidence - not just a “done” message. Use this record as the source of truth for every deployment decision.

Record Scope, Risk, and Approvals

The PM maintains the record, including approved scope, named approvers, validation criteria, recovery steps, and the deployment window. Before execution, record both the technical lead’s readiness approval and the client’s release approval so each decision can be traced.

If SQL, scope, execution settings, or recovery assumptions change, stop and review the change again.

Verify Schema, Data, and Application Behavior

QA must verify schema, data, and application behavior in staging, then repeat those checks after the production deployment. After launch, QA records the results, while DevOps records system health, errors, and latency issues.

The technical lead reviews the staging and production evidence before closing the record. That evidence determines whether to proceed or stop.

Separate Expansion, Backfill, Cutover, and Cleanup

Split expansion, backfill, cutover, and cleanup into stages, each with separate owners and approvals. DevOps executes only approved production steps.

Treat destructive cleanup as a separate approved change, not an automatic final step. This keeps irreversible actions behind their own approval gate.

Choose and Test a Recovery Plan

Application rollback and database recovery are different tasks. Older code does not restore changed data, and schema rollback does not recreate deleted records.

Require a tested runbook, verified restore capability, and human-approved recovery time and recovery point objectives. Record who can authorize recovery, whether writes stay open, pause, or queue, and which checks must pass before traffic resumes.

Do not ship without a tested recovery path.

Assign Incident Authority Before Deployment

A recovery plan needs a person in charge when deployment fails. Before deployment, name the technical lead or delegated human incident commander, a backup, and an escalation contact. Agents may carry out only approved containment actions. Any decision outside that approval goes back to the human lead.

Set Stop Conditions and Escalation Rules

Write measurable stop conditions into the runbook. Specify which compatibility, data integrity, or security failures need immediate escalation. For each trigger, state whether DevOps should pause queued batches, halt the active operation, or wait for human direction.

DevOps monitors execution and carries out approved containment. QA checks the impact, Builder drafts repairs, and Reviewer validates them. PM shares status updates and escalates client-facing issues to the human lead. If the incident commander is unavailable, page the named backup rather than give agents more authority.

After a stop condition triggers, use the incident log and verification trail to determine whether recovery can resume.

Verify Recovery and Assign Follow-Up Actions

After containment, move from execution to verification and closure. Keep an incident log linked to the migration ID, including the timeline, recovery-check results, and communication status. Treat uncertain impact as unresolved until QA verifies it.

QA independently checks data correctness and application behavior. The human incident commander authorizes recovery and closure after QA signs off. Then review root causes, missed gates, test gaps, and ownership gaps. Give every corrective action a named owner and a due date.

How Appeneure’s Human-Led Agent Team Works

Appeneure puts the same ownership model into practice this way:

Conclusion: Name Owners Before the Next Migration

Before the next release, lock in three things: owner, proof, and fallback.

AI can draft the migration. Humans own scope, review, verification, and release. After the technical lead confirms readiness, the client authorizes the exact change that was reviewed.

Before deployment, check each item:

• Owner: Name the person with final release authority.
• Approved scope: Record the exact schema, data, and application changes.
• Verification: Attach Reviewer findings and QA results checked against acceptance criteria.
• Release authorization: Tie client approval to the reviewed migration version.
• Stop conditions: Define when to halt and how to escalate.
• Recovery plan: Document and test the recovery procedure.

If the migration changes after approval, repeat review and verification, then renew release authorization. Approval belongs to the reviewed change, not the agent that drafted it.

FAQs

Can one person approve both technical readiness and release?

Yes, one person can approve both technical readiness and release, but verification duties should stay separate. The human technical lead or client stakeholder gives final deployment approval based on independent checks by the reviewer and QA agents.

The human lead decides scope, product behavior, and matters involving the client relationship. Merges to main and production releases require human sign-off based on the team’s evidence. The approver doesn’t need to perform every check personally.

How can I detect data errors that staging tests miss?

Treat AI-generated code as a draft, not a finished product. Use strict type definitions to validate data, and write tests before building features so expected outcomes are clear. Run those tests against every agent-generated change.

Have a human technical lead review milestone results and check business logic. Keep database interactions sandboxed in staging to avoid unintended effects on production, and require human approval for deployments.

What if my migration cannot be safely reversed?

Prevent problems with thorough testing and architecture planning. Never connect AI agents directly to a production database. Validate migrations and check their results in a staging environment that mirrors production. Use strict type definitions and integration tests that cover all system interactions as guardrails.

Document every architecture decision and migration script in an Architecture Decision Record. This gives the human technical lead a clear record to audit before approving deployment - only after verification succeeds.