Should AI write directly to your database, or only suggest changes for a human to approve?

A client asked me a version of this question recently, and it wasn't abstract. They had an LLM cleaning up duplicate customer records in FileMaker — matching names, merging addresses, flagging obvious typos. It worked well in testing. Then it merged two different customers who happened to share a name and a city. Nobody caught it for three weeks, until an invoice went to the wrong company.

Nothing in the system was "broken." The AI did exactly what it was built to do: find likely duplicates and act on them. The mistake wasn't in the model. It was in a decision nobody had explicitly made — that the AI should write, not just suggest.

This is the question every team building AI into a database eventually has to answer, and most answer it by accident rather than on purpose.

Why this isn't really a technical question

It's tempting to frame this as a capability problem — "is the model accurate enough to trust with writes?" That framing leads teams astray, because accuracy isn't the variable that matters most. A 98%-accurate AI making 10,000 changes a day will still make 200 wrong ones. The real question is: what does it cost you when it's wrong, and how long before someone notices?

Those two variables — cost of error, and time-to-detection — matter far more than model quality. A highly accurate AI that fails silently in a high-stakes field is more dangerous than a mediocre one that fails loudly in a low-stakes field.

A framework: four zones, not one line

Instead of treating "AI writes vs. AI suggests" as binary, it helps to think of it as a spectrum with four practical zones.

Zone 1: Autonomous write, no review Reserved for changes that are reversible, low-stakes, and easy to detect if wrong — timestamping a record, incrementing a counter, tagging a record with a category the AI is well-calibrated on. If it's wrong, the blast radius is small and obvious.

Zone 2: Autonomous write, logged and reviewable The AI writes immediately, but every change is captured in an audit trail a human can scan later. This works for medium-stakes, high-volume tasks — like the duplicate-matching example above — if the log is actually reviewed on a schedule, not just stored and forgotten. This is the zone most teams think they're in, but actually aren't, because nobody owns the review step.

Zone 3: AI proposes, human approves before it writes The right default for anything touching money, contracts, compliance-sensitive fields, or anything hard to reverse (merges, deletions, status changes that trigger downstream workflows). The AI does the work of finding and drafting the change; a human still has final say. This is slower, but it's the zone that actually earns trust over time, because people can watch the AI be right repeatedly before zone 2 or zone 1 becomes reasonable.

Zone 4: AI advises only, never touches the record For anything genuinely high-consequence — legal determinations, medical or safety-related fields, anything where an error creates liability. Here the AI's output belongs in a note, a suggestion field, or a separate report — never in the system of record.

Most failures I've seen come from putting a task in zone 1 or 2 when it actually belonged in zone 3.

What actually determines the zone

A few questions, asked honestly, usually settle it:

• Is the change reversible? A merged record is much harder to undo cleanly than a re-categorized one.
• How long until a wrong write is noticed? If the honest answer is "whenever someone happens to look," that's a vote for zone 3, regardless of accuracy.
• Does the change affect anyone outside your team? Invoices, customer-facing records, and anything that triggers an email or a payment should default to human approval.
• Can you measure the AI's real-world error rate, or are you still guessing? Teams often move something from zone 3 to zone 2 the moment testing looks good — but testing accuracy and production accuracy on messy, real data are not the same number.
• Who is accountable if it's wrong? If nobody can answer this clearly, the task isn't ready to leave zone 3.

Where FileMaker developers have an advantage — and a blind spot

If you've built FileMaker systems for a while, you already have instincts for this. Script triggers, validation calluses, and conditional value lists all exist because someone decided, at some point, that certain changes needed a checkpoint before they hit the table. AI-write decisions are the same instinct applied to a new kind of actor.

The blind spot is speed. A script trigger runs once, predictably, on an event you defined. An LLM-driven process can generate hundreds of writes in the time it takes to notice something's wrong — and unlike a runaway script, it won't throw an error when it's confidently incorrect. Traditional FileMaker error-handling assumes failures announce themselves. AI failures often don't. That changes what "reviewable" needs to mean: a log field isn't enough if nobody has a habit of checking it.

A practical checklist before you let AI write

• Is the change reversible within your normal workflow, not just theoretically?
• Does a wrong write get noticed within a day, or could it sit unnoticed for weeks?
• Is there an audit trail that records what the AI changed, when, and on what input?
• Does someone have it on their calendar to actually review that trail?
• Have you measured error rate on real production data, not just a test set?
• Is there a single owner who's accountable if this goes wrong?
• Would you be comfortable explaining this decision to the customer it affects?

If any answer is "no" or "not sure," the task belongs in zone 3 — AI proposes, human approves — until that changes.

FAQ

Doesn't requiring human approval defeat the purpose of automation? Not if the goal is scale over time. Zone 3 isn't a permanent state — it's how a team builds evidence that an AI process is trustworthy enough to graduate to zone 2. Skipping straight to autonomous writes is how you end up debugging a bad merge three weeks after it happened.

What if review becomes a bottleneck? That's a real trade-off, and it's worth solving with better UI (batch approval screens, confidence-based routing where only low-confidence changes need review) rather than by removing the checkpoint entirely.

How do I know when it's safe to move a task from human-approved to autonomous? Track the approval rate over a meaningful volume of real cases. If a human is approving AI suggestions unchanged 99%+ of the time over hundreds of cases, the checkpoint has become a formality rather than a safeguard — that's a legitimate signal to reconsider, not a reason to remove logging.

Does this apply differently to LLMs than to traditional automation? Yes. Traditional automation is deterministic — the same input produces the same output, so you can test it exhaustively. LLMs are probabilistic, and their failure modes are often plausible-looking rather than obviously broken, which is exactly why they need more, not less, of a review habit around them.

The actual answer

There's no universal rule for whether AI should write to your database. There's a rule for how to decide: match the level of human oversight to the cost of being wrong and the time it takes to notice. Most teams get this backwards — they grant autonomy based on how impressive the AI's demo looked, not based on what happens when it's wrong at 2am on a Friday, unreviewed, for three weeks.

Start every new AI-database integration in zone 3. Earn your way out with evidence, not optimism.