Why the guarantees belong in the database
Application checks answer "did we remember here". That question accumulates with every endpoint you add.
Automation belongs everywhere except the acts a regulator holds a person accountable for.
There is real work for automation in this process. Chasing missing evidence, walking a borrower through an approval, following up on stalled draws, drafting a resolution summary — all of it is repetitive, and all of it is currently done by people who would rather be doing something else.
There are also three acts where automation should be refused outright, and being specific about which is more useful than a policy about responsible AI.
These are precisely the acts that consumer lending enforcement in this market is about. They stay with an accountable person.
Not in a system prompt, and not in a route guard. A prompt is guidance, and a route guard protects the routes someone remembered to guard. The refusal belongs in the data layer, where it also covers the endpoint nobody has written yet — which matters more than usual here, because agent capability is expanding faster than anyone's threat model.
An instruction not to do something is not a control. A system that cannot do it is.
That last point is the one most easily got wrong. A reviewer column full of service accounts reads as scrutiny to anyone skimming.
Ask a vendor to name the acts their automation cannot perform, and where that refusal is enforced. Vagueness here is the answer.
Pick a closed project. We will show you the document you would hand a regulator. If it does not answer the question, nothing else matters.