An AI underwriting tool can produce a perfectly reasonable IRR and still give a weak investment case. That sounds contradictory, but it can happen when different assumptions offset one another. A model might overestimate achievable revenue while also overstating construction costs, or assume stronger rents while using a longer lease-up period. The final IRR can land close to what an experienced analyst expects even though the assumptions driving it are materially different.
This is one of the harder problems to identify in AI-assisted real estate underwriting because the error isn't necessarily visible in the headline result. The spreadsheet may calculate correctly, the output may look professional, and the IRR may even match an existing model. The real question is whether the reasoning behind that IRR can survive scrutiny.
A Correct IRR Doesn't Prove a Correct Underwrite
IRR is an output of a financial model. It isn't an explanation of why the investment works. A development model can calculate IRR correctly while using weak comparable evidence, unrealistic absorption, unsupported rent growth, incorrect development timing, or assumptions that were never properly validated. Sensitivity analysis is important precisely because a single base-case return can hide how dependent the investment case is on individual assumptions and changes in those assumptions.
Consider a hypothetical development where an AI model assumes sales prices that are somewhat higher than the market evidence supports, but also assumes construction costs that are higher than the project's likely cost. The optimistic revenue assumption pushes the return upward while the conservative cost assumption pulls it downward. The final IRR may look reasonable even though neither assumption accurately represents the project. If an analyst only checks whether the IRR looks plausible, the model can pass the review. If the analyst investigates the assumptions, the weakness becomes much easier to see.
The Problem Is Hidden Inside the Assumptions
Real estate underwriting is essentially a network of assumptions connected through a cash-flow model. Revenue depends on pricing, rents, occupancy, unit mix, absorption, and timing, while costs depend on construction pricing, professional fees, contingencies, financing, taxes, and the development schedule.
AI can calculate the relationships between those variables very quickly, but calculation speed doesn't validate the inputs. A model can be mathematically consistent while being economically questionable.
This is why the more useful question isn't simply, "What is the IRR?" The stronger question is, "Which assumptions produced this IRR, and what evidence supports them?"
That distinction becomes particularly important when AI is responsible for assembling the initial underwriting model. The system may be capable of producing a complete-looking model before an analyst has had an opportunity to challenge the assumptions that matter most.
Two Wrong Assumptions Can Accidentally Produce the Right Answer
One of the most dangerous situations is when errors cancel each other out. Imagine an AI underwriting model assumes that achievable sales prices are higher than the market evidence supports. At the same time, it assumes a longer development timeline than the project team currently expects. The higher revenue pushes the IRR upward, while the extended timeline increases carrying and financing costs and pushes the return downward.
The final IRR might end up close to the expected range. That doesn't mean the model is reliable. If the development timeline is corrected while the inflated sales assumption remains, the return could move substantially. The original output wasn't necessarily wrong from a mathematical perspective; the problem is that it gave the appearance of a sound investment case without accurately representing the underlying economics.
This is why comparing an AI-generated IRR with an existing model isn't enough to validate an underwriting system.
Sensitivity Analysis Exposes What the Base Case Hides
Sensitivity analysis is one of the most practical ways to identify whether a seemingly correct IRR depends on questionable assumptions. Instead of accepting the base case, the analyst can change the variables that have the greatest potential effect on the investment outcome and observe how the return responds.
For a development project, that could include sales prices, rents, construction costs, absorption, financing rates, development timing, exit assumptions, or the acquisition price. The objective isn't to create an endless collection of scenarios. It is to identify the assumptions that can materially change the investment case.
A good AI underwriting system should make this type of testing easier rather than encouraging users to rely on a single polished base-case output. Platforms such as Aprao, for example, currently provide development pro formas, cash-flow forecasting, residual land value, and sensitivity analysis, with its AI positioning built around connecting natural-language workflows to an auditable financial-modeling engine.
The important idea is that AI should make it easier to investigate the model, not make the model harder to question.
AI Can Make Weak Assumptions Look More Credible
Another problem is presentation quality. A manually constructed model with questionable assumptions may attract attention because the analyst knows which inputs are estimates. An AI-generated model can appear much more complete from the beginning, with organized assumptions, formatted outputs, charts, and calculated return metrics.
That can create a dangerous shortcut: the cleaner the model looks, the more credible the underlying assumptions may feel. But presentation quality doesn't improve evidence quality.
A sales assumption doesn't become reliable because an AI system entered it into an Excel model. A comparable property doesn't become relevant because an algorithm selected it. A construction estimate doesn't become accurate because the resulting IRR is displayed to two decimal places. The analyst still needs to investigate the evidence supporting material assumptions.
The Model Should Explain the Drivers Behind the IRR
A useful AI underwriting tool should help an analyst move backward from the return metric into the assumptions that created it. If the IRR changes, the analyst should be able to determine whether the movement came primarily from revenue, costs, timing, financing, exit value, or another part of the model. That requires more than showing the final result; it requires a relationship between assumptions, calculations, and outputs that can be inspected.
This is becoming an important theme in AI-assisted underwriting. Feasibilitypro.AI, for example, currently combines market research, feasibility-model generation, scenario analysis, and Excel-based model analysis. Its product information describes fully functional Excel workbooks with formulas intact, editable assumptions, source information for model values, and the ability to run sensitivity tests. That type of workflow is useful because the analyst can move from the initial output back into the actual model rather than treating the AI's answer as a standalone conclusion.
The Same IRR Can Represent Completely Different Investment Cases
Consider two development models that both produce a 17% IRR. The first model assumes conservative sales pricing but relatively aggressive construction costs. The second uses a higher sales assumption but assumes lower construction costs and a faster development program.
The headline return is identical, but the underlying investment cases are not. The first project may be primarily exposed to construction efficiency. The second may depend heavily on achieving a particular sales price and completing the project within an aggressive timeline. This is why investment committees and experienced underwriters need to understand the composition of the return, not just the return itself.
A similar principle appears in newer AI underwriting platforms. AIRE describes an underwriting engine that combines stress testing, debt structuring, Monte Carlo analysis, and an explainable risk grade, while keeping assumptions and inputs reviewable by the underwriting team. Its current platform materials explicitly describe the system as AI-assisted rather than AI-controlled.
The specific implementation can differ, but the underlying requirement is the same: the return needs to be understandable rather than simply generated.
The Wrong Reasons Matter More When AI Scales
A questionable assumption in one manually prepared model is a problem. A questionable assumption repeated across hundreds of AI-generated underwriting models is a much larger problem. Suppose an AI system consistently applies an optimistic rent-growth assumption to a particular market. If the model is used to screen a large acquisition pipeline, the same bias can influence numerous investment decisions before anyone notices the pattern. That makes governance increasingly important as AI becomes part of the underwriting workflow.
The system should preserve information about the assumptions used, the evidence supporting them, material changes, and human overrides. Northspyre, for example, currently combines financial modeling with deal management, scenario comparison, sensitivity analysis, and centralized deal information, allowing teams to compare assumptions and projected outcomes across opportunities rather than relying on a single static model. The more opportunities the system evaluates, the more important these controls become.
How to Test Whether the AI Got the Right Answer for the Right Reasons
The strongest test is to use a real historical development where your team already understands the original underwriting and the eventual project outcome. Run the same information through the AI system and compare the results, but don't stop when the IRRs match. Examine the revenue assumptions, cost assumptions, development schedule, financing structure, exit assumptions, and comparable evidence that produced the result.
Then start changing the important variables. Reduce the achievable sales price, increase construction costs, extend the development schedule, change the financing assumptions, and adjust absorption. Ask the system to explain the effect of each change and identify which assumptions are responsible for the largest movement in returns.
The objective isn't to prove that the AI should reproduce the historical model perfectly. The more useful test is whether an experienced analyst can understand how the system reached its conclusion and whether the assumptions are defensible. A matching IRR is therefore only the beginning of the validation process.
AI Underwriting Should Make the Investment Case More Defensible
A useful AI underwriting workflow shouldn't stop at answering, "What is the projected IRR?"
It should help answer the questions that come afterward: What assumptions are driving the return? Which assumptions have the weakest evidence? What happens when those assumptions change? Where does the project stop meeting the required return? Which variables deserve further investigation before capital is committed?
That's where the distinction between AI-generated underwriting and AI-assisted underwriting becomes important. The objective isn't to have the system make the investment decision. The objective is to make the analytical process faster while preserving enough transparency for experienced professionals to review and challenge the result. The model should therefore expose the investment case rather than simply calculate its headline return.
The Real Test Is Whether the Reasoning Survives
An AI underwriting model doesn't need to produce a dramatically different IRR to be useful. What matters is whether the return is supported by assumptions that the investment team can understand, challenge, and defend.
If two inaccurate assumptions happen to cancel each other out, the model shouldn't receive credit for being accurate simply because the final IRR looks reasonable. The stronger standard is to ask whether the reasoning behind the number remains credible when the assumptions are challenged.
That means reviewing the evidence, tracing the calculations, testing the major sensitivities, and understanding which variables actually carry the investment case. For real estate teams, that's the difference between an AI tool that produces the right number and one that produces a decision the team can actually stand behind.
Top comments (0)