How we use AI on databases while engineers retain control

AI shortens diagnosis on production databases. It reads logs faster than a person, spots anomalies across metrics, drafts runbooks and proposes query improvements. Execution stays human: every change is approved and applied by a named engineer through the client's change process, AI access remains read-only, and client data stays inside the client environment.

Why this deserves a written policy

Plenty of infrastructure firms now describe themselves with AI language. Very few say what the tooling actually touches. For anyone handing over production databases, that silence is the problem: the useful question is what the model can reach, and who acts on what it says.

So we publish the boundary rather than the buzzword. What follows is the working method, and clients are welcome to hold us to it.

Where AI genuinely helps

Reading logs at volume

A database incident generates thousands of log lines. A person scans them serially; a model reviews the window at once and surfaces correlations worth checking. This turns a forty-minute hunt into a five-minute review of three candidates. The engineer still decides which candidate is real.

Anomaly detection across metrics

Baselines drift. Storage growth accelerates gently until it becomes urgent. Query latency creeps by milliseconds a week. Statistical comparison against historical behaviour catches those trends early, which converts a future incident into a planned change.

Drafting runbooks and documentation

Documentation lapses because writing it competes with doing the work. A model drafts the first version from the actions taken during an incident, and the engineer corrects and approves it. The result: estates that are documented rather than estates that were meant to be.

Proposing query and index improvements

Execution plans are dense. Tooling reads them quickly and suggests an index or a rewrite. Every suggestion is then tested against a representative workload, because a change that helps one query frequently harms three others.

The three guardrails

1. A named engineer approves and executes every change. Suggestions arrive as recommendations to a person, who evaluates them and applies them through your change process. Autonomous action against production sits outside the method entirely.
2. Access stays read-only, and advisory. Tooling reads logs and metrics. Credentials and write access remain with the engineer, held in named accounts your organisation issues and revokes.
3. Client data remains in your environment. What leaves are logs and metrics you have approved for collection. Personal data, business records and credentials stay where they are.

Why read-only matters more than the model

Discussion about AI safety in operations often fixates on which model is used. The more consequential question is architectural: what can the tooling reach, and what can it change?

A read-only integration has a bounded failure mode. Its worst outcome is a wrong suggestion, which a competent engineer catches during review. A write-capable integration has an unbounded failure mode, because a confidently wrong action executes at machine speed against live data. We choose the bounded one, and that choice holds regardless of how capable models become.

What we establish before tooling reaches an estate

• Which log and metric streams are in scope, agreed in writing with you
• Where those streams travel, and how long they persist
• Which accounts the tooling uses, and the permissions attached
• How suggestions reach the engineer, and how approval is recorded
• How you audit the whole path afterwards

These questions are worth asking of any provider who mentions AI, ourselves included. Clear answers indicate a considered method; vague answers indicate marketing.

Where engineers stay essential

Judgement under uncertainty remains human work. Deciding whether to fail over during a partial outage weighs business context that lives outside any log. Choosing to accept a slow query for a fortnight because a release is landing is a trade-off a person owns. Telling a client that their architecture is the actual problem takes a professional relationship.

The tooling makes engineers faster at the mechanical parts, which leaves more attention for the parts that genuinely require thought. That is the whole ambition, stated plainly.

The short version

AI reads. Engineers decide. Your data stays yours. If a provider describes their AI usage in terms that leave you unsure which of those three holds, ask again until the answer is specific.