When the Server Dies and the Auditor Calls: How AI Saved a Two-Hour Data Rescue

Here's the thing about AI: it's easy to call it useless until you hand it something genuinely scary. Not a blog post. Not a stock image. A real, messy, we-might-get-sued problem.

Last week, I got that call. A client's old HIS (hospital information system) server had been decommissioned—wiped, gone, two hours prior. The new system was live, but the old box still held years of historical data. And then the医保飞检 (medical insurance flight inspection) came knocking. They wanted records. Specific, time-bound, field-by-field records.

No server. No documentation. No one who remembered the passwords. Just a database that might still exist somewhere inside a decommissioned machine.

This is the story of how I pulled it off in two hours with two AI tools—and what it taught me about actually using AI under pressure.

The Setup: Four Problems Hidden in Plain Sight

When someone says "just write a SQL query," they're ignoring the four landmines underneath:

• How do you even connect to a database with no public IP, no port, no credentials?
• What's the internal code for each institution in the system?
• Which tables actually hold prescriptions and insurance settlements?
• How do you define "all settlements" without accidentally mixing in pre-settlements, refunds, or voided records?

The hardest part wasn't the SQL. It was getting into the database at all.

Phase One: Doubao Gets Us Connected

The server had no public IP. It was inside a private network. I was outside. No client installed—though DBeaver saved us from that—but still: no IP, no port, no username, no password.

I decided to bring in Doubao, a Chinese AI assistant, as my real-time collaborator. The workflow was simple: I'd screenshot what I saw, paste the error, and Doubao would interpret, suggest next steps, and point me where to look. I'd execute and report back.

First hurdle: no public IP. Doubao walked me through network reachability checks—how to make an invisible server reachable from outside. Then came the guessing game of ports and credentials. Bit by bit, error by error, we narrowed it down.

This wasn't a copy-paste exercise. Every wrong guess led to a dead end. But Doubao didn't get frustrated. It just kept asking what I saw. And after maybe forty minutes of this, the database finally opened.

That connection was the foundation. Without it, nothing else mattered.

Phase Two: Codex Takes Over the Query

Once connected, I switched to Codex—OpenAI's coding agent—for the heavy lifting. I gave it sanitized connection parameters (real IPs and passwords stay out of this article), and it started with a minimal verification: check the port, confirm the login, then move on.

Codex didn't rush. It read the data dictionary first—table names, comments, column names, comments. That's like looking at a city map before knocking on doors. Through keyword searches like "prescription," "医嘱," "医保," it mapped the business chain:

• Prescription main table: CLINICAL_SHEET
• Prescription details: CLINICAL_SHEET_DETAIL
• Outpatient orders: OPD_MADE_ORDER
• Drug details: OPD_MADE_ORDER_DRUG
• Drug master: HOSPITAL_ORDER

The comments even explained relationships—like how prescription details link to outpatient orders via OPD_ORDER_ID. That turned a guess into an evidence-based decision.

Finding the Right Institution Codes

The request mentioned two real institutions. The trap: if you filter by name, you might get zero rows because the system stores internal codes. If you use a similar code by accident, you'd silently pull data from the wrong place. Codex queried the institution dictionary, then used the correct internal codes. Locked down.

Translating Business Rules into Audit-Ready SQL

The client had a reference script from a previous inspection. Codex read that logic and turned it into explicit rules:

• Use OPD_BILL_SETTLEMENT for official settlements
• TYPE_ID = 2, and SETL_ID must not be null
• Join to outpatient registration, patient master, receipts, and bills
• Exclude voided receipts and registration-only bills

It even handled a subtle data-quality issue: some doctor names in the request had ambiguous spacing. Codex cross-checked against the system's standardized names and documented the handling rule. No guessing—just verification.

Data Validation: Because Exporting Isn't Enough

Codex exported the results as UTF-8 with BOM CSV (so Excel opens it cleanly). But then it did something I didn't expect: it ran a quick health check. Row count, duplicate settlement IDs, number of unique doctors, earliest and latest settlement timestamps.

That caught a potential disaster. The numbers looked right, but only after that validation did I feel confident sending them out.

The Twist: Wrong Logic Discovered the Next Day

You'd think the story ends there. It didn't.

The next day, while reviewing the data with the client, we found the取数逻辑 (data extraction logic) was off for certain fields—like "total cost," "amount into overall planning," and "fund payment." The fields didn't match real business definitions. If we'd submitted that, the consequences would've been serious.

So we went back to Codex. Round after round of comparison, correction, verification. The client confirmed which rule was correct. I fed that back. Codex adjusted the logic, we re-ran, and finally the numbers aligned.

Then Codex did something valuable: it saved that verified logic as a reusable SQL script. Next time this HIS needs insurance data, we won't start from scratch.

The Real Skill Isn't SQL—It's Closing the Loop

Looking back, the hardest part wasn't writing SQL. It was rebuilding a production capability from an abandoned environment. The division of labor was clear:

• Doubao handled the connection nightmare—no IP, no client, no credentials—turning a dead server into a reachable database.
• Codex took over from there: verifying the connection, analyzing schema, writing SQL, exporting data, and iterating on business logic with me.
• I provided the business context, verified conditions, and owned the final result.

That's a closed loop: minimal verification first, read metadata before querying, write business rules explicitly, validate every output, and keep sensitive data minimal and masked.

Why AI Feels Weak Until You Need It

Most people try AI on low-stakes tasks: a weekly report, a cute image, a translated paragraph. Of course it feels flat. The magic shows up when the task is hard, uncertain, and high-stakes—like a decommissioned server and a compliance deadline.

That's when AI stops being a toy and becomes a teammate. But only if you know how to use it: what context to give, what to check, how to feed back corrections, and when to take responsibility.

In two hours, I went from "this might take all day" to "done and verified." And when we found the logic error later, I wasn't panicked—because I knew we could fix it. That's the productivity of AI done right.

No hired team. No expensive consultants. Just me, two AI tools, and a clear process. That's the new superpower.