# The First 90 Days of a Mortgage AI Deployment: The Controls We Stand Up Before the Agent Touches a Live File

*September 11, 2026 · 6 min read · Pranay Shetty*

> Most mortgage AI deployments fail at the start, when the agent goes live before the controls that make it safe exist. The first 90 days are a control build, not a rollout. What we run in shadow mode before the agent touches a file, why the go-live gate is set per control instead of globally, and how deploying controls-first is also the posture an examiner expects to see.

## The Mistake Is Almost Always at the Start

I have watched enough mortgage AI projects to know where they go wrong, and it is rarely the model. It is the start. A lender buys or builds an agent, sees it perform well in a demo, and points it at live files, because the whole reason to buy it was to get work done and a pilot that does not touch real loans does not feel like progress. Ninety days later the same lender is either untangling a problem the agent created or has quietly turned it off, and in both cases the root cause is the same: the agent went live before the controls that make it safe to be live existed.

The first ninety days of a deployment are a control build, not a rollout. That framing is unpopular because it looks slower, and it is the thing that separates a deployment that survives an examination from one that becomes the reason a lender swears off AI. I want to describe what we actually do in those ninety days, because the sequence is the product as much as the agent is, and because the sequence is also, not by coincidence, the posture a regulator expects to see when an AI system sits anywhere near a credit or servicing decision.

## Shadow Mode Before the Agent Decides Anything

The first thing we do is the thing that feels like doing nothing: we run the agent in shadow mode, in parallel with the humans who do the work today, on real loans, producing real outputs, with the humans still making every decision. The agent reads the file, calculates the income, clears the condition, boards the loan, whatever the task is, and its output goes into a comparison, not into the loan. Nobody's decision changes. We are buying one thing with that period, which is evidence about where the agent agrees with careful human judgment and where it diverges, measured on live volume rather than on a curated test set.

Shadow mode is where I have caught the failure that would have been expensive. On one early deployment the agent looked strong on aggregate agreement, high enough that a team eager to launch would have launched, and the divergence was concentrated in a specific cohort of files where the agent's reading broke in a consistent way. On the average it was accurate. On the cohort that mattered it was not, and the average was hiding it. The decision we made from that, and have kept, is that we do not go live on a task until agreement holds on the hard cohort, not just the overall number, because the whole point of measuring is to find the place the agent fails, and an aggregate accuracy figure is designed to hide exactly that place.

That is why shadow mode is not a formality we rush through. It is the measurement that tells us whether the agent is ready for a specific task, and it produces the record that a validation function, and later an examiner, can read to see that readiness was established before anything went live rather than asserted after.

## The Agent Is a Model, So It Is Governed Before Use, Not After

When a supervised banking organization relies on an agent whose output is a quantitative input to a credit or servicing decision, that agent sits inside model risk management, and [SR 11-7](https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm), the guidance the Federal Reserve and the OCC issued, governs it across its whole lifecycle: development, implementation, use, and validation. SR 11-7 defines a model as a quantitative method that turns input data into estimates, so it reaches the agent whose reading feeds a decision as a number rather than every piece of software in the workflow, and a nonbank lender outside the guidance's direct scope still meets the same expectation through its own supervisors and the investors who buy its loans. The word that matters either way is "before." SR 11-7 expects a model to have documented intended use and limitations, independent validation that it performs as intended including at the boundaries where it is likely to fail, and ongoing monitoring, and it expects those to exist as conditions of use, not as things a lender adds after an issue surfaces.

So the governance is a gate we pass through in the first ninety days, not a document we backfill in month six. Before an agent goes live on a task, it has a written statement of what it does and what it does not do, a validation done by people other than the ones who built it, and a monitoring plan tied to outcomes that actually matter, the defects a downstream [quality-control review](/blog/ai-mortgage-quality-control-pre-funding-post-close-100-percent-coverage) finds on loans the agent touched and the rate at which humans reverse what the agent proposed. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) sits alongside SR 11-7 and its Govern function makes the same point in AI-specific terms: accountability, roles, and the risk decisions get set up before the system is deployed and used, because an AI system can fail in ways a statistical scorecard cannot, and someone has to own those failure modes by name in advance.

I am not describing this because compliance asked for it. I am describing it because a deployment that skips it is the one that breaks, and the governance record is the cheapest insurance a lender can buy against the two outcomes that kill these projects: a borrower harmed by an agent nobody was monitoring, and an examiner who finds an ungoverned model in the credit path.

## The Go-Live Gate Is Per Control, Not Global

The instinct on launch day is to flip one switch and turn the agent on. We do not do that, and the reason is that "the agent" is not one decision, it is many, and they do not carry the same risk. An agent that generates a document checklist and an agent that clears a condition that feeds an underwriting decision are the same software doing two jobs with very different consequences if they are wrong. So the go-live bar is set per task, and we launch the lowest-harm, highest-volume work first, keep a human confirming anything that reaches the borrower or the credit file, and hold the higher-consequence tasks in shadow mode longer until their own agreement bar is met.

There is a number people always want here, so I will give it with a caveat. An illustrative target we hold internally is agreement with independent re-review in the high nineties on the critical controls before a task goes live, and the honest version of that statement is that the figure is set per control with each lender, not declared once for the whole agent. A checklist task and an income-calculation task do not deserve the same bar, because the cost of being wrong is not the same, and a single global accuracy threshold is a way of pretending they are. The gate is the point, not the number, and the gate is different for different work.

Two more things ship with go-live because a control you cannot exercise is not a control. There is a rollback, a way to take a task back to human-only immediately if monitoring shows the agent drifting, and there is a monitoring surface that watches the outcomes that matter rather than the ones that are easy to chart, so that a developing problem is something we see in the data early instead of learning about from a complaint. Launching without those is how a small model problem becomes a large book problem before anyone notices.

## Why Controls-First Is Also the Defensible Posture

The part that took me longest to appreciate is that the controls-first sequence is not a tax on speed, it is the same thing the examiner is going to ask for, done in the right order. When a supervisor looks at an AI system in a lending or servicing process, the question is whether it was governed as a model with a validation record dated before it was used, or whether governance was retrofitted after something went wrong. Those two files read completely differently, and only one of them is a story the lender wants to tell. A deployment that stood up shadow-mode evidence, a validation record, per-task go-live gates, and live monitoring before the agent touched a decision has, as a byproduct, exactly the documentation an [examination of model risk](/blog/model-risk-management-ai-agents-sr-11-7-nist-rmf) expects to find.

So we do not treat the ninety-day control build as the boring part before the real deployment. It is the deployment. The agent is capable on day one; what takes ninety days is proving where it is safe to rely on, building the record that proves it, and standing up the gates and the monitoring that keep it inside the envelope it was validated in. At Sei we run every mortgage deployment this way, shadow first, governed before use, gated per control, monitored on the outcomes that matter, because I have seen both versions of the first ninety days, and the version that feels slower is the only one that is still running at day ninety-one. The agent does the work. The controls decide whether the lender ever regrets letting it.

---

_Source: [https://www.seiright.com/blog/first-90-days-mortgage-ai-deployment-controls-go-live-gates](https://www.seiright.com/blog/first-90-days-mortgage-ai-deployment-controls-go-live-gates) · Sei AI_