Most project leaders treat Legal as a gate they need to get through. That’s backwards. Legal isn’t the gate. They’re the risk owners who get personally exposed if something goes wrong.
A bank’s General Counsel doesn’t lose sleep over efficiency gains. They lose sleep over regulatory fines, enforcement actions, and having to explain to the board why an AI system made a bad call on a $300 million collateral package.
Your job is not to sell them on AI. Your job is to make it safe for them to say yes, and to prove you've already done the hard work of identifying what could go wrong.
Most project leaders won’t even know where to start. Here’s an actionable step-by-step process you can use.
Step 1: Map the Existing Process End-to-End (Including the Messy Parts)
Before your team touches a single line of AI code, you need to document exactly what happens today, not the idealized version in the procedure manual, but what actually happens on the ground.
What to do:
Shadow someone doing the reconciliation work for a full day. Watch where they pause, where they double-check, where they call someone for clarification.
Document every decision point: what triggers a document being accepted, what triggers a rejection, what triggers an escalation.
Identify where human judgment is actually exercised versus where it's just pattern recognition.
Capture the volume: how many documents per day, what percentage get flagged, what percentage get rejected, what the error rates are.
What to avoid:
Don't rely solely on process documentation. It's almost always outdated or idealized.
Don't assume you know which steps are repetitive until you've watched someone do them. Sometimes what looks repetitive actually involves subtle judgment calls.
Why this matters for Legal:
When you eventually present to Legal, you need to be able to say, "Here's the current state, here's where human error happens today, and here's the specific risk we're already carrying." That shifts the conversation from "Is this risky?" to "Is this more or less risky than what we're already doing?"
Step 2: Define the AI's Role Precisely, and What It Will NEVER Do
This is where most AI proposals go off the rails. They describe the AI as if it's going to handle the reconciliation process, which sounds to Legal like the AI is making decisions. You need to be surgically precise about what the AI does and, just as importantly, what it does not do.
What to do:
Draw a clear boundary: Explicitly mention that “The AI extracts data from documents and flags discrepancies. It does not make any determination about whether a document is valid or acceptable."
Define the AI as a pattern-matching and extraction tool, not a decision-maker.
Articulate where human review sits in the workflow: Explicitly mention that "Every flagged item and every final determination is made by a human reviewer. The AI is advisory only."
If the AI is handling document intake and classification, specify that it routes documents to the right queue but does not approve or reject anything.
What to avoid:
Don't use vague language like "the AI will help with reconciliation." Legal will fill in the gaps with their worst-case assumptions.
Don't position the AI as replacing humans. Position it as augmenting them, reducing drudgery so they can focus on the judgment-heavy parts.
Why this matters for Legal:
Regulators are increasingly clear that high-impact AI systems need human oversight. By drawing a bright line between AI-assisted extraction and human decision-making, you're giving Legal a compliance-ready architecture from the start.
Step 3: Conduct a Risk Impact Assessment Before Legal Asks for One
This is the single most important piece of doing the work for Legal. Don't wait for them to request a risk assessment. Prepare one proactively, and make it thorough.
What to do:
Assess the AI's risk materiality across three dimensions: impact, complexity, and reliance. For collateral reconciliation, impact is high (incorrect reconciliation could affect a $300M loan), complexity is moderate (document extraction and matching), and reliance is moderate (humans still make final calls).
Identify specific failure modes: What happens if the AI mis-extracts a key date? What if it misses a discrepancy? What if it hallucinates data that isn't there?
Quantify the business impact of each failure mode. Don't say "it could cause problems." Say "if the AI mis-extracts the collateral value by 10%, it could delay the loan closing by X days, costing the bank $Y in lost interest."
Map each risk to existing controls: Which controls already exist in the manual process that would catch this error? Which new controls need to be added?
Align your assessment with recognized frameworks. The NIST AI Risk Management Framework is widely referenced in banking. MAS and RBI frameworks emphasize similar elements: fairness, explainability, consumer impact, and resilience.
What to avoid:
Don't downplay risks. Legal will see through it and lose trust.
Don't treat this as a one-time exercise. Frame it as a living document that will be updated as the system evolves.
Don't ignore third-party risks. If you're using a vendor's AI model, Legal will want to know about data confidentiality, audit rights, and liability allocation.
Why this matters for Legal:
You're giving them a ready-made risk register that they can review, tweak, and sign off on, rather than having to build one from scratch. You're also showing that you've thought through the hard questions before they even asked.
Step 4: Design the Human-in-the-Loop Architecture With Specifics
Human-in-the-loop is not a get-out-of-jail-free card. Regulators and legal teams are increasingly skeptical of generic references to human oversight. They want to know: WHO reviews, WHAT they review, WHEN they review it, and HOW it's documented.
What to do:
Specify the review trigger: "Every document that the AI flags as having a discrepancy is automatically routed to a human reviewer within the collateral team."
Specify the reviewer qualifications: "Reviewers must have at least X years of experience in collateral reconciliation and have completed the bank's training on AI-assisted review."
Specify the review scope: "The reviewer validates the AI's extraction against the original document, confirms or overrides the AI's flag, and documents their rationale."
Specify the documentation standard: "All review decisions are logged with timestamp, reviewer ID, AI confidence score, and reviewer rationale. Audit trail is immutable."
Design escalation paths: "If the reviewer is uncertain, the document escalates to a senior reviewer. If the senior reviewer is uncertain, it escalates to Legal."
What to avoid:
Don't assume that human review means the human reads everything. That defeats the purpose of automation. Be clear about what the human reviews (exceptions, flags, high-risk items) versus what the AI handles autonomously.
Don't leave the escalation criteria ambiguous. Legal will want to know exactly when and how things get escalated.
Why this matters for Legal:
You're giving them a defensible oversight architecture. When a regulator asks "How do you ensure AI doesn't make bad decisions?", legal can point to this documented review process, not just say "a human checks it."
Step 5: Build the Explainability Artifacts Before They Ask
Banks are increasingly expected to explain how their AI systems make decisions. For document extraction and reconciliation, this is actually easier than for many AI use cases, but you still need to prepare the artifacts.
What to do:
Document the AI's decision logic in plain language. Not technical jargon, plain English that a regulator or a non-technical legal reviewer can understand.
For each extraction or flag, prepare to show: what data the AI used, what patterns it identified, and what confidence score it assigned.
If using a vendor model, get the vendor to provide explainability documentation upfront. Don't wait for legal to ask.
Prepare sample outputs: Show examples of correct extractions, examples of flags, and (critically) examples of where the AI got it wrong (and how the human reviewer caught it).
What to avoid:
Don't treat explainability as a technical exercise. It's a communication exercise. The goal is to make the AI's behavior understandable to someone who isn't a data scientist.
Don't hide the failures. Legal will respect honesty about limitations more than they'll respect a polished but incomplete picture.
Why this matters for Legal:
When a regulator or auditor asks "How does this AI work?", Legal needs to be able to answer confidently. You're giving them the ammunition.
Step 6: Prepare the Vendor/Procurement Package (If Applicable)
If you're using a third-party AI tool, Legal will want to review the vendor contract through a specific lens. Do this work upfront.
What to do:
Review the vendor contract for: data usage rights (does the vendor use your data to train their model?), liability allocation (who bears responsibility if the AI makes a mistake?), audit rights (can the bank audit the vendor's model?), termination rights (what happens if the bank wants to stop using the tool?)
Ensure the contract explicitly prohibits the vendor from using bank data for model training or pooling data across clients.
Get the vendor's security and compliance certifications (SOC 2, ISO 27001, etc.) upfront.
Document the vendor's model validation and testing practices.
What to avoid:
Don't assume the standard vendor contract is sufficient. AI vendors often have terms that are optimized for their protection, not yours.
Don't wait until legal asks for the contract. Have it ready, with the key provisions highlighted and explained.
Why this matters for Legal:
Contract review is one of the biggest time sinks for Legal teams. By pre-flagging the key issues and proposing language, you're saving them hours of work.
Step 7: Create the Full Submission Package, Make It Review-Ready
This is where you bring everything together. The goal is to hand legal a package so complete that their review is essentially a confirmation, not an investigation.
The package should include:
Executive summary (1 page): What the AI does, what it doesn't do, the business case, and the risk assessment conclusion.
Current state process map (2-3 pages): Visual and narrative description of today's manual process, with pain points and error rates identified.
Proposed AI architecture (2-3 pages): What the AI does, where it sits in the workflow, what it never does, and how humans interact with it.
Risk impact assessment (5-10 pages): Failure modes, business impacts, existing controls, new controls, residual risk ratings.
Human oversight design (2-3 pages): Who reviews what, when, how it's documented, escalation paths.
Explainability artifacts (3-5 pages): Plain-language explanation of how the AI works, sample outputs, error examples, and how they're caught.
Vendor/technical due diligence (as applicable): Contract review, security certifications, model validation documentation.
Implementation and monitoring plan (2-3 pages): Pilot approach, success metrics, ongoing monitoring cadence, drift detection, periodic review schedule.
Training plan (1-2 pages): How users will be trained on the AI system and on their oversight responsibilities.
What to avoid:
Don't make it a firehose of information. Structure it so Legal can read the executive summary and dive deeper where they have questions.
Don't use technical jargon without explanation. Legal reviewers may not be AI experts.
Don't present this as "Here's our proposal, please approve." Present it as "Here's our proposal, and here's why we believe it's safe. We'd welcome your input on any areas where you see additional risk."
Why this matters for Legal:
You're making it easy for them. Instead of having to request documents one by one and chase down answers, they have everything in one place. Their job becomes review and refine, not investigate and build.
Step 8: Frame the Conversation As "We've Done the Work, Now Help Us Make It Better"
How you present the package matters as much as what's in it.
What to do:
Lead with risk, not with efficiency. Open with: "We've identified the following risks in the current manual process, and we've designed an AI-assisted approach that we believe reduces those risks. Here's our analysis; we'd like your eyes on it."
Acknowledge what you don't know. Say: "We've done our best to identify the risks, but we know there may be things we've missed. That's why we're bringing this to you early."
Position Legal as a partner, not an obstacle. Say: "We want to make this as safe as possible. Your input on the risk assessment and controls would be invaluable."
Be transparent about limitations. If the AI has known failure modes, surface them. Don't wait for Legal to discover them.
What to avoid:
Don't say "We need this approved by next week." That triggers defensiveness.
Don't say "This is low risk" without backing it up. Legal will interpret that as naivety.
Don't treat Legal's questions as pushback. Treat them as valuable input that makes the project stronger.
Why this matters for Legal:
You're respecting their expertise and their risk exposure. You're not asking them to rubber-stamp something. You're asking them to help you make it better. That's a much easier ask to say YES to.
What to Watch Out For (The Traps)
Trap 1: Over-promising on accuracy. Don't claim the AI is 99% accurate unless you have the data to back it up, and even then, be careful. Legal will remember the 1% failure rate.
Trap 2: Under-estimating the pilot. Start with a low-risk pilot that doesn't touch live production. Use it to gather real data on accuracy, failure modes, and human reviewer workload. Then use that data to refine your risk assessment and your pitch to legal.
Trap 3: Ignoring data privacy. Collateral documents often contain sensitive client information. You need to address how data is handled, stored, and protected, and how the AI model is trained without compromising client confidentiality.
Trap 4: Treating this as a one-time approval. AI systems drift over time. Legal will want to see a plan for ongoing monitoring, periodic re-validation, and change management. Build that into your package from the start.
Trap 5: Forgetting about model risk management. Banking regulators expect AI systems to be managed through the same model risk frameworks as other quantitative models. If your bank has a model risk management function, engage them early, not just Legal.
Let’s be honest, the fear of "Legal won't approve it" is very real, but it's often a proxy for something else: Legal doesn't have enough information to feel safe saying YES.
Your job is to give them that information, not in a defensive "please approve this" way, but in a collaborative "here's what we've built, here's why we think it's safe, and here's where we need your expertise" way.
Do the work. Build the package. Make it easy for them. And most importantly, make it safe for them to say YES.