An Approval Ladder for AI-Assisted Website Changes
How should a small business decide who must approve an AI-assisted website change?
Classify an AI-assisted website request by what could go wrong, not by how quickly the AI produced it. Use routine review for reversible drafts that contain no sensitive information and cannot affect the live site. Require named approval for customer-facing claims, uploads, code, integrations, customer or employee information and any direct publishing action. If the operator cannot verify the output or determine the applicable rule, pause the change and escalate it.
Check whether the request is allowed at all
Training should make clear which AI tools are approved, which teams can use them, what use cases are allowed, which tools are off limits and what to do when a tool is not approved. Stop the request if the tool, operator, use case or information type is not already permitted by your business rules.
Sources: How to Train Employees to Use AI Safely | Ajaia.
Use Approve AI Tools and Vendors to decide whether a proposed service may enter the workflow before assessing the individual website change.
- Approved tool
- Authorised user
- Permitted use case
- Permitted information
- Clear escalation route
Place the change on the approval ladder
Training helps employees recognise mistakes and verify AI-generated output before relying on it. Hallermann Consulting recommends routine review for a reversible non-sensitive draft, named approval for a public claim or information handling, and stronger approval for code, integrations or live-site changes.
Sources: AI Training for Employees: What Every Organization Needs to Know.
Use AI Website Governance Rules to formalise your ladder, and use Vibe-Coded Website Before Launch when generated functionality needs deeper validation. Before an irreversible or service-affecting step, confirm the provider’s current prerequisites in its own documentation.
- Routine review: reversible non-sensitive draft
- Named approval: public claim or information handling
- Stronger approval: code, integration or live change
- Escalation: unclear rule or unverifiable output
Record the decision and preserve separation of duties
NIST’s AI Risk Management Framework says policies and procedures can help systematise AI roles and responsibilities throughout the AI lifecycle. Keep a compact record with the requester, business purpose, operator, source material, checks performed, reviewer, approver, release decision and rollback owner.
Sources: Govern - AIRC.
Use Recurring Website Task Ownership to assign practical owners where a small team cannot dedicate a different employee to every step. Where possible, the operator should not approve their own high-consequence change; if roles must combine, have the accountable owner make the release decision.
- Requester and business purpose
- Operator and source material
- Checks performed and reviewer
- Approver and release decision
- Rollback owner
Stop and escalate when the answer is unclear
Safe AI training should teach employees how attackers can use AI for phishing and impersonation. Pause for suspected impersonation, an unusual access request, unclear information handling, unverifiable output or an unapproved use case.
Sources: How to Train Employees to Use AI Safely | Ajaia.
Escalation is a successful outcome when the operator cannot establish a safe answer; do not reward confident guessing or direct publishing.
- Suspected impersonation
- Unusual access request
- Unclear information handling
- Unverifiable output
- Unapproved use case
Consequence-based website change triage table
Use this Hallermann Consulting triage table for one proposed website change at a time. Select the row that best describes the consequence of an error, then follow the listed human decision and action.
| Change characteristic | Recommended decision | Human action |
|---|---|---|
| Reversible internal draft with no sensitive information and no live-site effect | Routine review | A reviewer checks accuracy and fit before the draft is used |
| Customer-facing statement or public claim | Named approval | Verify the supporting source material and obtain approval before publication |
| Customer or employee information | Authorised owner decision | Confirm the permitted handling rule or stop and escalate |
| Code, integration, live configuration or direct publishing | Stronger authorised approval | Review, test, name a rollback owner and release only after approval |
| Unclear rule, suspicious request or unverifiable output | Stop and escalate | Do not proceed until the accountable owner resolves the uncertainty |
The ladder is a practical recommendation, not a mandated classification. Escalate whenever more than one row applies or the team cannot verify the change.
When this is not the right approach: Do not use this lightweight ladder to bypass specialist review for a change involving obligations, security exposure or technical complexity that the team cannot assess. It is also not a substitute for provider documentation before service-affecting work.
Related guidance
What follow-up questions matter most?
- What comes before the approval ladder?
- Check the proposed tool, user, use case and information involved. If any of those is outside the approved operating rules, pause the request rather than assigning a normal review level.
- When is named approval needed?
- A named approver should decide on customer-facing claims, information handling, code, integrations and direct publishing. The operator can prepare the work but should not self-approve a high-consequence change.
- What should the change record contain?
- Record the requester, operator, source material, checks performed, approver, release decision and rollback owner. A small team can keep this record simple while preserving accountability.
What steps does this workflow follow?
Use the AI-assisted website change approval ladder
- Screen the request: Confirm that the tool, user, website use and information type are already allowed.
- Identify the consequence: Consider public exposure, information sensitivity, technical access, reversibility and the consequence of an incorrect output.
- Choose the human decision: Use routine review only for low-consequence work; route consequential work to a named approver.
- Record and release: Record the decision, checks, approver and rollback owner before release.
- Pause uncertainty: Stop and escalate when the output cannot be verified, the information rule is unclear or the request appears suspicious.