Most AI teams write model cards for other AI teams. They document architecture choices, training data characteristics, and benchmark performance — the things engineers care about.
Legal and compliance teams need something different. When a lawyer asks to review your AI system before deployment, they're asking a different set of questions:
- What decisions does this system make or influence?
- Who is affected, and how?
- What happens when it gets it wrong?
- How do we audit it after the fact?
A model card that can't answer those questions in plain language isn't a governance document. It's a research paper.
What we've learned from the governance stage
Over the last two years, we've helped organisations get AI systems through legal review — mostly in financial services and professional services, where the scrutiny is highest. Here's what consistently works.
Start with the use case, not the model
Don't open with "This is a fine-tuned LLaMA-3 model trained on..." Open with: "This system helps loan underwriters assess document authenticity. It flags documents for human review but does not make final decisions."
Legal doesn't need to understand transformers. They need to understand what the system does in the real world.
Be explicit about what the system doesn't do
One of the most effective things you can add to a model card is a clear list of out-of-scope uses. "This system is not designed for and must not be used to..." This sets expectations, creates a record of intent, and helps with liability arguments later.
Document the human in the loop — precisely
"Human oversight is in place" is not enough. Document who reviews outputs, what they're reviewing for, how cases are escalated, and what authority they have to override the system. The more specific this is, the better the governance story holds up.
Include failure mode documentation
What does the system do when it's uncertain? What types of inputs cause it to fail? How do you know when it's drifting from its intended behaviour? These questions have technical answers, but they need to be written for a non-technical reader.
Define your evaluation framework upfront
One of the most frequent blockers we see is that a team has a working model but no systematic way to demonstrate that it's working correctly. Before legal review, you need:
- A test set that represents the real distribution of inputs
- Defined pass/fail criteria for each output type
- A regression process that runs before each deployment
This isn't just good engineering practice — it's the evidence base your governance documentation refers to.
The thing that actually gets AI through legal review
The teams we've seen succeed at the governance stage are usually the ones who involved a legal or compliance stakeholder early — not to get sign-off, but to understand what sign-off would require.
That conversation often reveals requirements that aren't in any framework document: specific audit log formats, particular approval chains, jurisdictional constraints nobody had thought about.
Getting legal in the room when you're designing the system is cheaper than redesigning the system to satisfy legal after it's built.
If you're working through AI governance and want a second opinion on your model card or documentation approach, we're happy to help.