Your firm already uses AI. Could you show it’s sound?

What we do. We review the AI tools your firm has already deployed and produce a written record of what they actually do with your material — what each vendor is contractually permitted to retain or train on, which of your data reaches which tool, where a person checks the output, and what happens when one gets it wrong. Two to three weeks. Fixed price.

Why an engineer and not a consultant. The method comes from safety engineering in nuclear power and commercial aviation: work backwards from what you can’t afford to have happen, find the states of the system that would cause it, then check whether the control that’s supposed to prevent it actually exists. It catches the failure a compliance checklist cannot — the tool working exactly as designed, producing an answer a person then relies on without checking.

What you get. An inventory of every AI tool in use, including the ones nobody approved. A written file of what each vendor’s contract permits. A map of what can go wrong, ranked by consequence. A register of findings with owners and dates. And a summary you can hand to a client, an insurer or your counsel.

We work backwards from what you can’t afford to have happen.

Most reviews start with a list of controls and tick them off. That produces a gap list, and it misses the way these systems actually hurt a firm — the tool performing exactly as designed, and a person downstream relying on the output without checking it. A model that invents a citation isn’t malfunctioning. It’s doing what it does. The accident happens in the handoff.

So we start with the losses: privilege waived, a sanction, a malpractice exposure, a client’s data somewhere it shouldn’t be, a conflict breached. Then we identify the states of your system that would lead to one. Then we ask four questions about each: what control is supposed to prevent this, does it exist in configuration and contract rather than intention, would it hold up at eleven at night with a rushed associate, and how would you know if it failed.

The method is named and version-numbered. Your report says which version produced it, and what we did not examine.

The Deployment Review Method, v0.1

1. Define the system. The tools — including AI features inside software you already own, and tools in use without approval — the people who use or rely on them, the data each can reach, and the decisions the output influences. What is left out is written down.
2. Identify the losses. What your firm cannot afford to have happen, in your terms. You confirm the list before the review goes on.
3. Identify the hazards. The states of the system that, on a bad day, lead to one of those losses.
4. Examine the controls. The four questions, asked layer by layer: vendor terms, configuration, access, human review, and monitoring.
5. Write the findings. Each with a proposed severity, a named owner and a closure date.
6. State the case, and its limits. A narrow, dated claim; the evidence behind it, traceable to what was examined; and what remains unresolved or fell outside the review.

AI Deployment Review

$7,500

Two to three weeks. Under four hours of your firm’s time.

First three engagements: $5,000, in exchange for permission to publish an anonymized case study.

Invoiced half at signature, half at the readout.

What we examine

Inventory

What AI is actually in use, including tools nobody approved and AI features switched on inside software you already own.

Vendor terms

For each tool: can the provider train on your inputs, how long does it keep them, can you make it delete them, and does the contract say so in writing.

Confidentiality and privilege

What client material reaches which tool, and whether that placement is defensible.

Access and segregation

Who can see what, whether matter data is kept apart, and whether a conflict wall survives a firm-wide assistant.

Human review

Where a person checks output before it leaves the firm, and where that check is assumed rather than real.

Failure modes

How each deployment could harm the firm, a client or a matter, ranked by consequence rather than likelihood.

Incident readiness

How fast you could stop a tool, who decides, and what you would tell a client.

What this is not

This is an engineering review. It is not a certification, and we are not an accountancy firm. It is not legal advice, a privilege opinion, or a conclusion that your firm complies with any rule. Where a finding has legal implications, the report says so and stops there; that judgment belongs to your counsel.

It is point-in-time, and the report carries its date. We don’t test against production systems or live client files. We don’t offer continuous monitoring.

About

Joe Hughes is a safety engineer with a background in high-consequence industries, where systems are required to demonstrate they are safe before they operate rather than after something goes wrong.

Deckplate applies that discipline to AI tools already running inside professional firms.

No AI products. No referral fees from vendors. The only thing we sell is the review.

Contact

Write to Joe directly: [email address to come]