Why GenAI projects get stuck in bank security reviews: seven questions compliance officers should ask engineering

Last winter, a regional bank's security chief brought us in. Their GenAI customer service assistant had been stuck in security review for seven months. Proof of concept was done. Business was pushing. But the security committee wouldn't move. In one meeting, I asked: 'Are you actually arguing about whether this model will fail, or whether anyone would be able to prove you caught it if it does?'

Nobody had an answer. That was the problem.

Most GenAI projects don't stall because of technical limits. They stall because compliance officers and security officers are asking completely different questions than what engineering is prepared to answer. Engineering shows up with a deck that says 92% accuracy. Compliance wants to know, 'When the regulator walks through the door, can you reconstruct exactly why this conversation went the way it did, in four hours?' This is the gap between those two worlds, and most projects fail trying to bridge it.

Auditability, not the model

Every blocked GenAI project we've encountered in banking has the same signature: they nailed 'can we use this' and skipped 'can we audit this.' The model was brilliant in the demo, but nobody could explain where the data went, where it stopped flowing, or who's liable when things break. In a regulated environment, a correct answer you can't trace back is riskier than a wrong answer you can prove.

Compliance officers don't need to become engineers. But you need to ask hard questions, ones hard enough to force engineering to show you the foundation. These are seven questions we run through before every compliance review even starts.

Seven questions compliance should ask engineering

First: Is data leaving the bank's network? Get specific about each piece: where does the prompt go, where does retrieved content stop, where does model output land? If you're using an external API, does the contract explicitly forbid training use and specify data retention windows? Most teams can only answer the first part.

Second: Can you trace every answer back to its source? If your RAG system can't point each output back to the exact source document and version it cited, you can't handle customer complaints and you can't pass an audit. Traceability isn't a nice-to-have; it's table stakes.

Third: When hallucinations happen, who sees them first and how does the system stop them? The real question is: where does the safeguard live? Is it hoping the model will behave because of your prompt, or is there actual independent checking, confidence thresholds, and forced handoff to a human when confidence drops? The first is prayer. The second is control.

Fourth: Do permissions follow the person or the model? An assistant that can access your entire knowledge base but doesn't inherit the user's actual data access rights is just an elaborate backdoor around your existing controls. This is the question most teams miss. It's also the most dangerous one.

Fifth: How much evidence are you keeping and for how long? Regulators often dig back years. What goes into your logs: input, output, what was cited, model version, timestamp? Logs that only capture output without context might as well not exist.

Sixth: Who re-validates when the model updates? Vendors upgrade their models quietly and often. Behavior that passed testing yesterday can shift tomorrow. You need version locks or regression testing discipline, otherwise your compliance posture is quietly degrading every week.

Seventh: When things break, which line of your contract covers it? The model gives bad financial advice, leaks customer data; where's the indemnification clause, what's the cap, how much risk do you self-insure? If you can't answer this one, the answers to the first six don't matter.

Compliance review as a design requirement, not a gate

Our experience: treat these seven as a 'we'll patch it after launch' checklist and 90 percent of projects hit a wall. Treat them as day-one design requirements and the review actually moves faster. The difference is whether your engineers are retrofitting foundations or whether they've built auditability, permission inheritance, and logging into the architecture from the start.

That's why when we do this work in banking, engineers sit directly in the security and compliance meetings instead of delivering a demo and walking away. At a bank, a beautiful demo doesn't count for anything. Passing review, surviving audits, having the business actually use it every day; that's what done looks like.