Working safely with AI

AI can change a lot of your site quickly. That is the point, and it is also the risk. A few habits keep the speed without the accidents.

Use a staging site for big changes

A staging site is a copy of your live site that visitors never see. Do large or uncertain work there.

Anything touching many pages at once belongs on staging: a migration, a bulk rewrite, a redesign of a layout, a script you have not run before. You look at the result as a whole, fix what is wrong, and promote it when you are happy. If it goes badly, you discard it and nothing was ever public.

For a one-line edit to one page, staging is overkill. Judge by blast radius, not by effort.

Review diffs before publishing

Read what actually changed, not the summary of what changed. Compare a staging site against live before you promote it, and check version history on individual items.

Look for what was quietly lost as well as what was added. Bulk edits are good at removing a line that mattered (a phone number, a disclaimer, a link) without mentioning it. AI writing is also fluent enough that a wrong fact reads exactly like a right one, so check anything a customer could act on: prices, hours, contact details, claims about qualifications.

Publishing is the human checkpoint

Draft and live are separate. Nothing an AI does reaches your visitors until someone publishes it.

Keep it that way. Ask for changes as drafts, and publish yourself once you have read them. That one step is what stands between a bad batch of edits and your customers seeing it. Do not build automation that publishes without a person looking, however tempting it is for a repetitive job.

Least access, for people and keys

Give each team member the smallest role that lets them do their job. An AI key carries exactly the permissions of the person who created it, so limiting roles limits keys automatically.

Remember that an API key is per user and reaches every organization that user belongs to. Someone who should only work on one client site needs their own account and their own key, not a copy of yours.

Custom roles are useful here. A role that can edit and draft but not publish or delete is a good fit for anyone experimenting with AI.

Revoke a leaked key immediately

If a key is pasted into a chat, committed to a repository, left on a lost laptop, or you simply are not sure where it has been, revoke it. Do it first and investigate afterward. Revocation is immediate, and creating a replacement takes a minute.

A key is a login without a password prompt. There is no partial precaution worth taking instead.

Version history is the undo

BrightSite keeps past versions of your content. If something is wrong, open the item's history, find the version from before the change, and restore it.

Use the activity log alongside it. The log tells you when a change happened and who made it, which is how you find the right version to go back to.

Where the checkpoint sits, per route

Lumi asks before doing anything significant. You approve, adjust, or reject, so there is a built-in pause.

An external AI tool has no such pause from BrightSite's side. Whatever approval prompts your own tool offers are the only checkpoint you get, so leave them switched on. Running a tool in a mode that approves everything automatically against a live client site removes the last thing standing between a mistake and your visitors.