Why AI Projects Fail in Real Estate: The Data Infrastructure Problem Nobody Wants to Talk About
There’s a pattern that plays out in real estate organizations with enough consistency that it’s almost predictable. Leadership mandates an AI initiative. The technology team evaluates vendors, selects a platform, and builds a proof of concept. The demo is impressive — the AI summarizes lease clauses, answers portfolio questions, scores deal flow, predicts maintenance failures. Stakeholders are excited. The budget is approved. The project moves to production.
And then it quietly stalls. Adoption is lower than projected. The outputs are inconsistent. The operations team stops trusting the results. The AI assistant produces confident answers that turn out to be wrong. The model that performed well on test data degrades on real production data. Six months after launch, the initiative is still described as “in progress” in board reports, but the honest answer is that it never made it.
This is not an unusual outcome. MIT’s Project NANDA published research in July 2025 covering more than 300 AI initiatives across industries through practitioner interviews and structured surveys. Their finding: 95% of organizations deploying generative AI saw zero measurable return on their investment. Not low return. Zero. The researchers define success as sustained productivity gains and documented P&L impact — and 95% of deployments didn’t meet that bar.
In real estate, the failure rate is, if anything, higher. JLL’s 2025 survey of more than 1,000 senior CRE decision-makers found that 92% are piloting AI — but only 5% report having achieved most of their program goals. The pilots are everywhere. The results are almost nowhere.
The reason is almost never the AI technology itself.
The Root Cause: Data Infrastructure That Was Never Ready for Production
When MIT, Gartner, and RAND analyze why AI projects fail — across industries and across deployment types — the diagnosis is consistent. A 2024 Capital One survey of 500 enterprise data leaders found that 73% identified data quality and completeness as the primary barrier to AI success, ranking it above model accuracy, computing costs, and talent shortages. Gartner’s 2025 research projects that 60% of AI projects lacking AI-ready data will be abandoned through 2026 — and that 42% of US companies are already at that abandonment point.
The data problem is real everywhere. In real estate, it’s structural.
Real estate data is recorded in different ways by different companies, often shaped by legacy software and local practice. A lease abstract in one portfolio may look entirely different from one in another. Property attributes may be labeled inconsistently across systems. Public records are typically published by county or state recorders who have little incentive to standardize formats beyond their own jurisdiction. The result is a fragmented data landscape that AI models simply cannot navigate reliably.
The fragmentation runs deeper than most real estate firms realize when they start their AI initiatives. Consider a mid-sized investment firm managing fifteen assets across three markets. The property management data lives in Yardi. The asset management projections live in Argus files and Excel models. The capital account records live in the fund administrator’s system. The deal pipeline history lives in a mix of Dealpath and email threads. The investor communications live in Outlook. The maintenance history lives in a property manager’s local system with a different chart of accounts than the fund-level reporting. The market data comes from CoStar and is exported to spreadsheets for analysis.
Every one of these data sources has a different schema, a different identifier for the same property, a different definition of occupancy, a different accounting period. In a typical US real estate fund structure, those issues are magnified by the sheer number of participants touching the same underlying facts: property managers, JV partners, asset managers, fund administrators, auditors, tax advisers, and valuation specialists, many using different charts of accounts and general ledger mappings. In practice, that means the same economic reality can look very different as it moves through the chain.
When this firm deploys an AI model on top of this data landscape and asks it to produce portfolio analytics, answer LP questions, or flag underperforming assets — the AI doesn’t have a clean, consistent, connected view of the data it needs to answer those questions reliably. It has fragments. And a model trained on fragments produces outputs that are sometimes right, sometimes plausibly wrong, and occasionally confidently wrong in ways that are hard to detect without deep domain knowledge. That’s the pattern that erodes trust and stalls adoption.
The 80/20 Problem: Most of Your Critical Data Is Invisible to AI
The structural problem compounds through what MIT’s Computer Science and Artificial Intelligence Laboratory calls the “80/20 problem” in enterprise AI deployments. Corporate databases capture approximately 20% of business-critical information in structured formats — the neat rows and columns that AI systems easily process. The remaining 80% exists in unstructured data: email threads, call transcripts, meeting notes, contracts, presentations, and external sources like news articles and regulatory filings. This unstructured data often contains the most decision-critical intelligence, but most AI systems never see it.
In real estate, that 80% is enormous. The seller’s motivation that came up in a phone call with the broker. The property manager’s institutional knowledge about which vendor to call for HVAC issues at a specific building. The lease negotiation history that explains why a tenant got a below-market rate and what the renewal expectations are. The due diligence concerns that were raised in an email thread and resolved with a verbal agreement. The market intelligence that a senior asset manager carries in their head from twenty years of operating in a specific submarket.
None of this is in a database. None of it is accessible to an AI model that was connected to the structured data layer and told to be helpful. And some of the most consequential decisions in real estate — whether to renew a lease at market, whether to proceed with an acquisition, whether to accelerate a capital call — depend on exactly this kind of context that the structured data layer doesn’t capture.
This doesn’t mean AI can’t help with real estate decisions. It means that AI models need to be scoped to problems where the relevant data is actually available in a usable form — not deployed as general-purpose analysts on data landscapes that are 80% invisible to them.
The “Someone Has a Spreadsheet Somewhere” Problem
You must avoid the “someone has a spreadsheet somewhere” problem: when someone owns a critical dataset that must be updated regularly, but these updates happen outside the normal processes. Take forecasting budget versus actuals — the rent runs powering this analysis might be exported to an Excel file.
This is the data governance failure that’s endemic in real estate organizations, and it’s the one that’s hardest to fix with technology alone. Critical datasets — the rent roll, the capital expenditure budget, the vendor contract database, the investor commitment schedule — live in spreadsheets that are owned by specific people, updated manually, and not connected to the systems that an AI model would need to access them through.
When the AI model is deployed and asked to answer questions that depend on these datasets, it either doesn’t have access to them at all or has access to a version that was exported last month and hasn’t been updated since. The model answers confidently using stale data. The operations team catches the error. Trust erodes. The AI initiative stalls.
The solution isn’t better AI. It’s replacing the spreadsheet with a managed, versioned, accessible data asset before deploying the AI. That’s data infrastructure work, not AI work — and it’s the work that the 5% of organizations achieving real results did first, before they selected their AI use cases.
The Five Specific Ways Real Estate Data Infrastructure Fails AI
The fragmentation and the 80/20 problem are the structural conditions. Here are the five specific data infrastructure failures that translate those conditions into failed AI projects in real estate:
Inconsistent entity resolution is the most pervasive technical failure. The same property is identified differently in every system it appears in — an Assessor’s Parcel Number in the county database, an internal property code in Yardi, a deal name in Dealpath, a street address in the CRM, and a building name in the asset management model. Without a master property record that links all of these identifiers to a single canonical entity, an AI model querying across systems will treat these as different properties, produce aggregations that double-count or miss assets, and answer cross-system questions with results that don’t reconcile. The challenge isn’t just missing data. It’s fragmented data that AI systems can’t reconcile. Entity resolution is the prerequisite for any AI application that needs to reason across multiple real estate data sources.
Missing historical depth limits predictive applications before they start. AI models that predict lease renewal probability, maintenance cost trajectories, or market timing require years of historical transaction data to produce reliable signals. A property management company that migrated to a new platform three years ago and didn’t bring the historical data with them has three years of history, not fifteen. The model trained on that history is predicting from a thin foundation. The predictions look confident and are structurally limited by the absence of the historical context that would make them reliable.
Metric definition inconsistency is the problem that produces conflicting outputs from models that are all technically working correctly. If occupancy rate means physical occupancy in the property management system, economic occupancy in the asset management model, and leased percentage in the reporting dashboard — and nobody has resolved these definitions before deploying an AI model — the model will produce different occupancy figures depending on which data source it draws from. The figures are all technically derivable from the underlying data. None of them are wrong in isolation. But they produce outputs that contradict each other and that no one trusts, because the definitions were never aligned before the AI was deployed.
Data latency mismatches create hallucinations in production that didn’t appear in testing. A test environment uses a clean, consistent snapshot of data taken at a single point in time. A production environment has data flowing from multiple systems at different update frequencies — the property management system updates in real time, the fund accounting system updates nightly, the market data platform updates weekly, the asset management model was last updated manually six weeks ago. The AI model in production is reasoning across data that reflects four different moments in time and producing answers that are internally inconsistent in ways that only manifest at the specific combination of stale and fresh data the production environment creates. This is the deployment failure that the demo never surfaces.
Governance gaps — the absence of defined ownership, update cadence, and quality standards for each data asset — are what allows all of the above problems to persist after they’re identified. Lack of governance leads to questionable data accuracy. Limited stakeholder buy-in results in fragmented implementation. Without a well-defined data strategy, AI tools may produce misleading results, overlook critical patterns or fail to integrate with existing workflows. Data governance in real estate organizations is consistently underdeveloped relative to the maturity of the AI ambitions being pursued on top of it.
What the 5% Did Differently
The organizations achieving real AI results in real estate didn’t have better AI models than the ones stalling at pilot stage. They made different decisions upstream — specifically, they built data infrastructure before selecting AI use cases rather than after.
The organizations in the 5% made different choices at the start of the project, not the end. They built data infrastructure before selecting use cases. They defined P&L metrics in week one. They co-designed workflows with the people whose jobs they were changing. None of those choices require a bigger budget. They require a different sequence.
In practical terms for real estate, that sequence looks like this. Before any AI vendor is selected or any model is deployed, the organization conducts an honest inventory of its data assets: what exists, where it lives, how current it is, who owns it, how it’s defined, and whether the definition is consistent across systems. That inventory almost always reveals the entity resolution gaps, the metric inconsistencies, and the spreadsheet-owned datasets that will undermine any AI deployment built on top of them.
The data infrastructure work follows: establishing a master property record with canonical identifiers that link across systems, migrating critical spreadsheet datasets into managed, accessible data stores, defining metrics consistently across the systems that will feed the AI model, and building the pipelines that keep those definitions current. This is the work that JLL calls “AI-ready data” — and Gartner’s operational definition requires that it be aligned to specific use cases, actively governed, supported by automated quality pipelines, and continuously quality-assured rather than audited at reporting cadences.
Only then is the use case selection meaningful. Because at that point, the question isn’t “what could AI theoretically do with our data?” It’s “given the data we actually have in a form AI can use, which specific problems can AI solve reliably?” That question produces a much shorter, much more tractable list of use cases — and a much higher probability of the deployment producing the results it promises.
The Zillow Case Study: When the Data Problem Is the Business Model
The most instructive data-related AI failure in real estate is Zillow’s 2021 iBuying shutdown — not because it was a typical failure mode, but because it illustrates what happens when an AI system is deployed in a consequential operational role before the data quality and model limitations are fully understood.
Zillow’s Zestimate model, applied to residential pricing, is genuinely strong in markets with deep comparable transaction data. Zillow’s iBuying operation required the same model to price homes it was committing to purchase — a context where the model’s error rate had direct financial consequences. Zillow shut down its home-buying division after its AI-powered pricing algorithm made catastrophic valuation errors, writing down approximately $500 million in overvalued inventory. The model that worked for consumer price estimates didn’t work for purchase decisions, because the tolerance for error is fundamentally different between a displayed estimate and a committed purchase price.
The lesson isn’t that AVM technology is unreliable — it isn’t, within its appropriate scope. The lesson is that deploying an AI model in a consequential operational role requires understanding not just its average performance but its error distribution, and ensuring the operational design accounts for the cases where the model is wrong. Zillow’s model was wrong at a rate that was acceptable for consumer use and unacceptable for institutional purchasing. The data infrastructure question — do we have enough comparable depth in this specific market, for this specific property type, at this price point, to trust this valuation for a purchase decision? — was the question that needed to be answered before the model was deployed in that role, not after.
The Practical Readiness Test
Before any real estate AI initiative moves past the pilot stage, four questions need honest answers. Not optimistic answers — honest ones.
Can the AI model access all the data it needs to answer the questions it will be asked in production? That includes the data currently living in spreadsheets, emails, and legacy systems that aren’t connected to the data infrastructure. If not, what’s the plan for that data before deployment, not after?
Are the metrics the model will report defined consistently across all the systems that feed it? If occupancy means different things in different systems, which definition will the model use, and has that been communicated to the people who will interpret its outputs?
What is the model’s error rate on the edge cases that matter most in production? Not just on the test dataset, but on the unusual properties, thin markets, and atypical lease structures. Is the operational design built to handle those errors gracefully, rather than treating the model as a black box that produces correct answers?
Who owns each data asset the model depends on, and how frequently is it updated? What is the process for catching and correcting errors in that data before they propagate to the model’s outputs? If the answer is “someone checks it periodically” or “whoever maintains that spreadsheet,” the governance isn’t ready for production AI.
These aren’t questions that should wait until after the AI system is live. They’re the questions that determine whether the system will be live and useful twelve months after deployment — or live and trusted by nobody, quietly waiting to be described as a learning experience.
If you’re building a real estate platform and thinking about where AI belongs in your product roadmap — or if you’re an operator who has run an AI pilot that stalled and wants to understand why before trying again — the real estate software development work we do includes data infrastructure assessment and AI readiness evaluation before any AI feature development begins. The use cases that will deliver real results are determined by the data you actually have, not the data the AI vendor assumes you have. Let’s start with an honest assessment of your data infrastructure before we talk about what AI can do with it.