Loading

Using It Safely

The features are useful and they are not judgement. A few habits keep the distinction clear.

Where to find it

Architect Panel → Data:

  • AI Builder — change sets, which need review before applying
  • Query Builder — the role that sees field names only

Architect Panel → Activity:

  • Activity Log — what an accepted change actually did

Know what each feature sends

They differ, and the difference matters more than any general policy:

  • Query Builder sends field names only — never a record value — and receives a query definition.
  • Blueprint and change-set features send a description of what you want and structural information about the application.
  • The code editor sends what you are working on.

None of these is "your database". Be able to say that precisely, because "we use AI" invites a much broader assumption than what is happening.

Everything is a proposal

Nothing is applied on its own. A change set is reviewed before it runs; a query is a definition you look at; generated source is code you read.

Preserve that. The value here is a good first draft quickly, and the risk begins where somebody stops reading the drafts.

Review change sets properly

The temptation is to accept a change set that looks right. Read what it will actually do, particularly anything touching permissions, deletion or existing data — a confidently wrong change set is more dangerous than an obviously wrong one, because it gets accepted.

Do not paste sensitive data into a prompt

The features are careful about what they send; a person typing into a prompt box is not constrained the same way. Real customer records pasted in as an example go wherever prompts go.

Use realistic but invented examples. It costs nothing and removes the question entirely.

Restrict who can use them

These features change your application. Access should sit with the people who would be allowed to make those changes by hand — the AI route should not be a way around a permission somebody does not have.

Generated code is code you own

Once accepted, nobody cares where it came from. It gets the same review, the same testing and the same maintenance as anything hand-written, and the fact that it was generated is not a defence when it misbehaves.

Tell people it is available

Rather than leaving it to be discovered. People who know a feature exists use it deliberately; people who find it by accident use it experimentally on live configuration.

Have an internal position

Which features are enabled, who may use them, what may be pasted into a prompt, and who approves an AI-produced change. A short written answer is worth having before the question arrives from a client rather than after.

Worked example

An organisation enables AI Builder for its two architects only, documents that Query Builder sends field names but never values, and adds one line to its developer guidance: generated changes are reviewed like any other change, and no real customer data goes into a prompt. A client's security questionnaire six months later is answered from that page.

Recommendations

  • Know and be able to state what each feature sends.
  • Review every change set — especially the plausible ones.
  • Restrict access to people who could make the change by hand.
  • Never paste real records into a prompt.