The Real Estate AI Operating Model in 2026

Real estate is moving fast. By 2026, the question isn’t whether AI will reshape your operations—it’s whether you’ll lead the shift or play catch-up. The difference between a competitive real estate business and a legacy one in 18 months will come down to one thing: a working AI operating model.

This isn’t about bolting chatbots onto your website or running a one-off proof of concept. It’s about baking AI into how your teams work, how you make decisions, and how you deliver value to clients. It’s about governance that doesn’t strangle innovation, vendor selection that doesn’t lock you in, and a clear path from your first pilot to portfolio-wide deployment.

This guide walks you through exactly how to build that operating model—the decisions you’ll face, the pitfalls to avoid, and the concrete steps to move from idea to impact in real estate.

Table of Contents

1. Why Real Estate Needs an AI Operating Model
2. The Five Pillars of a Real Estate AI Operating Model
3. Governance Without Gridlock
4. Build vs Buy: The Real Estate Decision Matrix
5. Vendor Selection and Avoiding Lock-In
6. The AI Maturity Curve: From Pilot to Portfolio
7. Security, Compliance, and Audit Readiness
8. Measuring What Matters
9. Getting Started: Your First 90 Days

---

Why Real Estate Needs an AI Operating Model

Real estate has always been relationship-driven, data-sparse, and process-heavy. You’ve got property managers juggling tenant communications, maintenance requests, and lease renewals manually. You’ve got acquisitions teams buried in due diligence spreadsheets. You’ve got sales teams chasing leads through email chains and CRM silos.

AI doesn’t replace those workflows. It accelerates them, automates the drudgery, and frees your best people to do what they do best: close deals, build relationships, and make strategic decisions.

But here’s the trap: most real estate businesses are throwing AI at individual problems—a chatbot for tenant inquiries, a valuation model for pricing, an AI agent to screen properties. Each tool works in isolation. The data doesn’t flow. The insights don’t compound. You end up with a patchwork of disconnected experiments instead of a coherent operating model.

According to McKinsey’s analysis of AI’s impact on real estate, the winners in 2026 will be those who’ve woven AI into the fabric of their operations—not bolted it on as an afterthought. That requires an operating model: a clear structure for how AI gets built, deployed, governed, and iterated.

An operating model answers five hard questions:

• Governance: Who decides what gets built? Who owns the AI? Who’s accountable when it fails?
• Build vs Buy: When do you build custom AI? When do you buy off-the-shelf? When do you use a partner?
• Vendor Management: How do you avoid vendor lock-in? How do you evaluate and replace tools without ripping out your entire stack?
• Deployment: How do you move from a one-off pilot to a repeatable, scalable process across your portfolio?
• Measurement: How do you know if the AI is actually working? What metrics matter?

Get those five things right, and you’ve got a machine that compounds. Get them wrong, and you’ll spend the next two years ripping out failed experiments and rebuilding.

---

The Five Pillars of a Real Estate AI Operating Model

A working AI operating model in real estate rests on five pillars. Each one is non-negotiable.

1. Clear Governance and Accountability

Governance doesn’t mean bureaucracy. It means clarity: who decides, who builds, who measures, and who’s accountable when things go wrong.

In most real estate organisations, this breaks down fast. The CTO wants to build everything in-house. The CFO wants to buy cheap SaaS. The COO wants to move fast and iterate. The General Counsel is worried about data privacy and liability. Nobody’s accountable, so nothing ships.

A real estate AI operating model needs a single decision-making body—call it the AI Steering Committee or the Technology Council—with representatives from operations, finance, legal, and technology. Their job: align on priorities, approve vendor contracts, measure outcomes, and kill experiments that aren’t working.

You also need a Chief AI Officer or equivalent—someone who owns the end-to-end operating model, not just one tool or one team. This person reports to the CEO and has the authority to say no to rogue projects and yes to cross-functional investments.

Finally, you need clear accountability for each AI system. One person or team owns each tool—its performance, its data quality, its compliance status. That owner is measured on outcomes, not on how many AI tools they’ve deployed.

2. Modular Architecture and Data Foundation

Real estate data is messy. You’ve got property data, tenant data, transaction data, market data, financial data—all in different systems, different formats, different levels of quality.

Before you build any AI, you need a data foundation. Not a data lake (those are graveyards). A modular, governed data platform where each system of record—your property management system, your accounting system, your CRM—feeds clean, standardised data into a central hub.

That hub doesn’t need to be fancy. It can be a warehouse (Snowflake, BigQuery, Redshift), a lakehouse (Databricks, Apache Iceberg), or even a well-organised data mart. The key is that it’s modular: each domain (properties, tenants, transactions, financials) has its own schema, its own governance, its own refresh cadence.

From that foundation, you can build AI systems that plug in and out without breaking the whole stack. You can swap vendors. You can add new capabilities. You can measure what’s working and what isn’t.

Without this foundation, you’re doomed to point-to-point integrations, data silos, and systems that can’t talk to each other.

3. Vendor Agnosticism and Build Discipline

In 2026, the real estate tech stack will include large language models (LLMs), vector databases, workflow orchestration tools, and domain-specific AI platforms. No single vendor owns all of it.

Your operating model needs to be vendor-agnostic. That means:

• Use open standards: APIs, not proprietary formats. Use OpenAI, Anthropic, or open-source models—not a single vendor’s locked-in LLM.
• Plug-and-play architecture: Your AI systems should work with multiple vendors’ tools. If you decide to swap from one LLM provider to another, it should take days, not months.
• Build where you have edge: Custom AI for your competitive advantage (valuation models, tenant matching, market analysis). Buy or partner for everything else (general automation, document processing, chatbots).
• Avoid lock-in contracts: Long-term vendor agreements are fine. Contracts that make it impossible to switch vendors are not.

This requires discipline. It’s tempting to buy an all-in-one real estate AI platform that promises to solve everything. It won’t. And when it doesn’t, you’ll be stuck.

Instead, build a modular stack: one tool for property data, one for tenant communications, one for market analysis, one for valuations. Each tool should be replaceable without breaking the others.

4. Continuous Measurement and Feedback

AI systems drift. Models degrade. Business conditions change. Your operating model needs continuous measurement and feedback loops.

For each AI system, define three metrics:

• Business outcome: Revenue, cost savings, time saved, deal velocity, tenant retention—whatever matters to the business.
• Model performance: Accuracy, precision, recall, latency—whatever tells you if the AI is working as designed.
• Operational health: Error rates, data quality, system uptime, cost per prediction—whatever tells you if the system is sustainable.

Measure all three weekly. When business outcomes drop, investigate. When model performance degrades, retrain. When operational costs spike, optimise.

This isn’t a one-time audit. It’s a standing practice, embedded in how your teams work.

5. Cross-Functional Delivery and Iteration

The biggest AI projects in real estate fail because they’re siloed. The technology team builds something in isolation, throws it over the wall to operations, and it doesn’t work because operations wasn’t involved in the design.

Your operating model needs cross-functional delivery from day one. That means:

• Product thinking: Every AI project has a product owner (usually from operations or business) who owns the user experience and the business outcome.
• Embedded engineers: Engineers work alongside operations teams, not separately. They understand the workflow, the pain points, the edge cases.
• Rapid iteration: Two-week sprints, not six-month waterfalls. Deploy, measure, iterate.
• User feedback loops: Every two weeks, show the AI system to the people who’ll actually use it. Get feedback. Change direction if needed.

This sounds obvious, but most real estate organisations still operate in silos. Technology builds in isolation. Operations doesn’t see the work until it’s done. By then, it’s too late to change course.

---

Governance Without Gridlock

Governance is where most real estate AI operating models die. Either there’s no governance (chaos), or there’s too much (gridlock).

The right level of governance depends on three things: the scale of the business, the risk profile, and the maturity of the team.

Governance for Early-Stage Real Estate (1–5 Properties or <$10M Revenue)

At this stage, you don’t need a formal AI Steering Committee. You need a single decision-maker—usually the CEO or the CTO—who owns all technology decisions.

Your governance model:

• Weekly syncs: 30 minutes, the CEO and the technical lead, reviewing what’s being built, what’s working, what’s failing.
• Monthly reviews: Review business outcomes from AI projects. Kill anything that isn’t working.
• Quarterly planning: Decide what to build next based on what you’ve learned.
• No formal approvals: If the CEO and technical lead agree, it ships. If they disagree, they talk it through and decide.

This works because there’s no bureaucracy, but there’s also no chaos. One person is accountable.

Governance for Mid-Market Real Estate (5–50 Properties or $10M–$100M Revenue)

At this stage, you need structure without bureaucracy. You’ve got multiple teams (acquisitions, property management, finance, technology). They need to coordinate.

Your governance model:

• AI Steering Committee: CEO, COO, CFO, CTO, General Counsel. Meets monthly.
• Working groups: One for each domain (property management AI, acquisitions AI, tenant communications AI). Meet bi-weekly. Report to the Steering Committee.
• Clear decision rights: The Steering Committee approves new AI projects >$50K or >3 months of work. Smaller projects are approved by the working group.
• Quarterly business reviews: Each working group presents outcomes, costs, and next steps. The Steering Committee decides what continues and what gets killed.

This structure keeps things moving while ensuring alignment across teams.

Governance for Enterprise Real Estate (50+ Properties or $100M+ Revenue)

At this scale, you need formal governance, but it still needs to move fast.

Your governance model:

• Chief AI Officer: Reports to the CEO. Owns the end-to-end operating model. Has a team of 3–5 people.
• AI Steering Committee: CEO, COO, CFO, CTO, Chief AI Officer, General Counsel, Head of Risk. Meets monthly.
• Domain councils: One for each major business unit (residential, commercial, acquisitions, asset management). Meet bi-weekly. Each council has a leader, an engineer, and a business representative.
• Approval gates: Projects >$100K or >6 months require Steering Committee approval. Projects <$100K require domain council approval. Projects <$25K require only the domain council lead’s sign-off.
• Monthly dashboards: Each domain council reports on all active AI projects: business outcomes, model performance, operational health, spend.

At this scale, you also need a Chief Data Officer or equivalent to ensure data quality and governance across all AI systems. This person works closely with the Chief AI Officer.

The One Rule: Clear Accountability

Regardless of scale, the one rule that makes governance work is this: every AI project has one person who’s accountable for its success or failure. That person is measured on business outcomes, not on how many projects they’ve shipped.

If the project fails, that person explains why. If it succeeds, that person gets credit. This creates accountability without blame.

---

Build vs Buy: The Real Estate Decision Matrix

Every real estate business faces the same question: should we build this AI system ourselves, or should we buy it off-the-shelf, or should we partner with someone to build it?

There’s no universal answer. But there’s a decision matrix that works.

The Build vs Buy Decision Matrix

For each AI project, score it on two axes:

Axis 1: Competitive Advantage

• Is this AI system a source of competitive advantage? Does it differentiate us from competitors? Will it help us win deals, reduce costs, or improve client outcomes in a way that’s hard to copy?
• Score: 1 (not at all) to 5 (massive advantage)

Axis 2: Complexity

• How complex is this system? Does it require deep domain knowledge? Does it require custom training data? Does it require ongoing maintenance and iteration?
• Score: 1 (simple, off-the-shelf) to 5 (complex, custom)

Now plot your project on the matrix:

High Advantage + High Complexity = BUILD Example: A proprietary valuation model that uses your historical transaction data and local market knowledge to predict property values more accurately than competitors. This is a source of competitive advantage and requires custom training. Who builds it: Your internal team, or a partner like PADISO’s AI & Agents Automation service who can co-build and hand off to your team.

High Advantage + Low Complexity = BUY (WITH CUSTOMISATION) Example: A tenant screening system that uses public credit data and rental history. This is a source of competitive advantage, but the underlying technology is standard. Who builds it: A vendor like Zillow or Redfin who’s already solved the problem, plus your team for integration and customisation.

Low Advantage + High Complexity = PARTNER Example: A complex workflow automation system that ties together your property management system, accounting system, and tenant communications. It’s not a source of competitive advantage, but it’s complex to build and maintain. Who builds it: A partner like PADISO who can build it, deploy it, and hand off to your team (or manage it ongoing).

Low Advantage + Low Complexity = BUY Example: A chatbot for tenant inquiries. It’s not a source of competitive advantage, and it’s simple to implement. Who builds it: An off-the-shelf tool like Intercom or Zendesk.

Real Estate Examples

Let’s apply this to real estate specifically:

Property Valuation AI

• Competitive advantage: High (if your valuations are more accurate, you make better acquisition decisions and better investment recommendations)
• Complexity: High (requires historical transaction data, market data, property characteristics, and ongoing retraining)
• Decision: BUILD (or partner to build)

Tenant Screening

• Competitive advantage: Low (most tools use similar data sources and algorithms)
• Complexity: Medium (some customisation needed for your risk profile and local regulations)
• Decision: BUY (with customisation)

Lease Renewal Automation

• Competitive advantage: Low (the process is standard across the industry)
• Complexity: Medium (requires integration with your property management system and tenant database)
• Decision: PARTNER (or buy a tool that integrates well)

Market Analysis and Investment Recommendations

• Competitive advantage: High (if your analysis is better, you’ll identify better opportunities)
• Complexity: High (requires market data, demographic data, economic indicators, and proprietary analysis)
• Decision: BUILD (or partner to build)

Maintenance Request Prioritisation

• Competitive advantage: Medium (faster response times improve tenant satisfaction)
• Complexity: Low (rule-based system with some machine learning)
• Decision: BUY (or build a simple system in-house)

The Partner Path

If you choose to partner, you have two options:

Option 1: Co-Build and Hand Off You partner with someone like PADISO for AI Strategy & Readiness to design and build the system, then hand it off to your internal team to maintain and iterate. This works well if you have the internal capacity and want to own the system long-term.

Option 2: Managed Partnership You partner with someone to build and manage the system ongoing. You focus on the business; they focus on the AI. This works well if you don’t have internal capacity or if the system is not core to your business.

Most real estate businesses should use a mix: build the systems that are sources of competitive advantage, buy the rest, and partner for the complex stuff in the middle.

---

Vendor Selection and Avoiding Lock-In

By 2026, your real estate tech stack will include multiple AI vendors. Choosing the right vendors and avoiding lock-in is critical.

The Vendor Selection Criteria

When evaluating an AI vendor for real estate, use these criteria:

1. Does it solve a real business problem? Not: “Does it have AI?” or “Is it shiny?” Yes: “Does it measurably improve our operations? Can we quantify the benefit?”

2. What’s the data portability? Can you export your data in a standard format? Can you switch vendors without losing your data or your model? Red flag: Vendor says “your data is locked in our system” or “you can’t export it.”

3. What’s the integration story? Does it integrate with your existing systems (property management, accounting, CRM)? Does it use standard APIs, or does it require custom integration? Good: REST APIs, webhooks, standard data formats (JSON, CSV). Bad: Proprietary formats, custom ETL, manual data entry.

4. What’s the model transparency? Can you understand how the model works? Can you audit it? Can you retrain it with your own data? Red flag: Vendor says “it’s a black box” or “you can’t see the model.”

5. What’s the pricing model? Is it per-user, per-property, per-transaction, or consumption-based? Does it scale linearly with your business, or does it have hidden fees? Good: Transparent, predictable pricing that scales with your business. Bad: Hidden fees, surprise charges, pricing that doesn’t scale.

6. What’s the support and SLA? If the system breaks, how fast do they fix it? Do they have 24/7 support? What’s the uptime SLA? For critical systems (property management, tenant communications), you need 99.9% uptime SLA and 24/7 support. For non-critical systems (analytics, reporting), 99% uptime is fine.

7. What’s the roadmap and stability? Is the vendor investing in the product? Are they adding features you need? Or are they stagnating? Red flag: Vendor hasn’t shipped a major update in 12 months.

Avoiding Vendor Lock-In

Vendor lock-in happens in three ways:

1. Data Lock-In Your data is stuck in the vendor’s system and you can’t get it out. Solution: Require the vendor to export data in standard formats (JSON, CSV, Parquet). Test the export quarterly to make sure it works.

2. Model Lock-In Your model is trained on the vendor’s proprietary platform and you can’t retrain it elsewhere. Solution: Require the vendor to provide model weights or allow you to retrain the model on your own infrastructure. Use open-source models (Llama, Mistral) instead of proprietary ones when possible.

3. Integration Lock-In Your entire stack is integrated with one vendor and switching would require ripping out the whole system. Solution: Use modular architecture. Each system should be replaceable without affecting others. Use standard APIs and data formats.

Real Estate Vendor Evaluation Example

Let’s say you’re evaluating two vendors for tenant screening:

Vendor A: TenantCheck AI

• Solves the problem: Yes. Screens tenants faster than manual review.
• Data portability: Yes. Exports data as CSV monthly.
• Integration: REST API. Integrates with your property management system.
• Model transparency: No. Black box model.
• Pricing: $50/screening, minimum $5K/month.
• Support: Business hours only, 48-hour response time.
• Roadmap: No major updates in 18 months.

Vendor B: PropertyShield

• Solves the problem: Yes. Screens tenants faster than manual review.
• Data portability: Yes. Real-time API export. You own the data.
• Integration: REST API + webhooks. Integrates with everything.
• Model transparency: Yes. You can retrain the model with your own data.
• Pricing: $30/screening, no minimums. Usage-based.
• Support: 24/7 support, 4-hour response time, 99.9% uptime SLA.
• Roadmap: Shipped 3 major updates in the last 12 months.

Vendor B is the better choice. It’s cheaper, more transparent, more integrated, and less risky. Vendor A locks you in and doesn’t have a clear roadmap.

Building Your Vendor Strategy

For a mid-market real estate business, a good vendor strategy looks like:

• 1 core property management system (Yardi, AppFolio, etc.). This is your system of record. Everything else integrates with it.
• 2–3 specialist AI vendors (tenant screening, valuation, market analysis). These are best-of-breed for specific problems.
• 1 data platform (Snowflake, BigQuery, Databricks). This is where all your data lives.
• 1–2 integration platforms (Zapier, Make, custom API layer). These connect the vendors.

Each vendor should be replaceable without affecting the others. Each should have clear data export capabilities. Each should have transparent pricing and a clear roadmap.

If you’re building custom AI, PADISO’s services can help you architect a vendor-agnostic stack that avoids lock-in while still moving fast.

---

The AI Maturity Curve: From Pilot to Portfolio

Most real estate businesses start with a pilot. One team, one problem, one AI system. If it works, they want to scale it across the entire portfolio. If it doesn’t, they want to kill it and move on.

The challenge: scaling a pilot to a production system is a completely different problem from running the pilot. You need to think about this from day one.

Stage 1: The Pilot (Weeks 1–8)

Goal: Prove that the AI system solves the problem and delivers measurable business value.

Scope: One team, one use case, one location (if applicable).

Team: 2–3 engineers, 1 product owner, 1 business sponsor.

Success metrics:

• Does the AI system work? (Model accuracy, latency, reliability)
• Does it solve the problem? (Time saved, cost reduction, improved outcomes)
• Would users adopt it? (User feedback, willingness to use it)

Deliverables:

• A working AI system (even if it’s rough)
• Clear metrics showing business value
• User feedback and learnings
• A plan for scaling (if successful) or killing it (if not)

Common mistakes:

• Pilots that are too ambitious in scope. Keep it small.
• Pilots that don’t measure business value. Measure everything.
• Pilots that don’t involve the actual users. Get feedback early and often.
• Pilots that are too polished. A rough system that works is better than a perfect system that doesn’t.

Stage 2: Hardening (Weeks 9–16)

Goal: Turn the pilot into a production-ready system.

Scope: Same team and use case, but with production-grade infrastructure, monitoring, and documentation.

Team: 3–4 engineers, 1 product owner, 1 business sponsor, 1 ops/support person.

What changes:

• Infrastructure: Move from a laptop or dev environment to production infrastructure (cloud, on-premise, or hybrid).
• Monitoring: Add logging, error tracking, and performance monitoring.
• Documentation: Document the system, the data, the model, the runbooks.
• Testing: Add unit tests, integration tests, and user acceptance testing.
• Security and compliance: Add access controls, data encryption, audit logging, compliance checks.
• Scalability: Optimise for the volume you expect at scale.

Success metrics:

• 99.9% uptime SLA
• <100ms latency (for real-time systems)
• <1% error rate
• Documented runbooks for common issues
• Security and compliance audit-ready

Deliverables:

• A production-ready system
• Monitoring and alerting
• Documentation and runbooks
• Security and compliance sign-off

Stage 3: Expansion (Weeks 17–26)

Goal: Expand the system to additional teams or locations.

Scope: 2–5 teams or locations using the same system.

Team: 2–3 engineers (maintenance), 1 product owner, 1–2 ops/support people, 1 change management person.

What changes:

• Customisation: Allow teams to customise the system for their specific needs (without forking the codebase).
• Training: Train teams on how to use the system.
• Support: Set up a support process for teams to get help.
• Data management: Ensure data quality across all teams.
• Change management: Manage the change process as teams adopt the system.

Success metrics:

• Adoption rate (% of teams using the system)
• User satisfaction (NPS or similar)
• Business value per team (cost savings, time saved, etc.)
• Support ticket volume and resolution time

Deliverables:

• Customisation framework
• Training materials and sessions
• Support process and SLAs
• Data quality standards

Stage 4: Optimisation (Weeks 27–52)

Goal: Optimise the system for cost, performance, and user experience.

Scope: All teams and locations using the system.

Team: 1–2 engineers (optimisation), 1 product owner, 1–2 ops/support people.

What changes:

• Performance tuning: Reduce latency, improve throughput.
• Cost optimisation: Reduce infrastructure costs, vendor costs, support costs.
• User experience: Improve the UI/UX based on user feedback.
• Model improvement: Retrain the model with new data, improve accuracy.
• Automation: Automate manual processes, reduce support burden.

Success metrics:

• Cost per prediction or per user
• Model accuracy and performance
• User satisfaction (NPS)
• Support ticket volume (should decrease as automation improves)
• Business value per team (should increase as the system improves)

Deliverables:

• Optimised system (faster, cheaper, better UX)
• Cost reduction (target: 20–30% reduction from Stage 3)
• Improved model accuracy (target: 5–10% improvement)
• Automation of manual processes

Stage 5: Scale (Ongoing)

Goal: Roll out the system to the entire portfolio and continuously improve it.

Scope: All teams, all locations, all use cases.

Team: 1–2 engineers (maintenance), 1 product owner, 1–2 ops/support people, 1 data engineer.

What changes:

• Portfolio-wide rollout: Deploy the system across the entire portfolio.
• Continuous improvement: Continuously improve the model, the UX, the performance.
• New use cases: Apply the system to new problems and new teams.
• Integration: Integrate the system with other AI systems and business processes.

Success metrics:

• Adoption rate across portfolio (target: >90%)
• Business value across portfolio (target: >$1M annually for a mid-market business)
• Cost per prediction or per user (target: <$0.10 for most use cases)
• Model accuracy and performance (target: >95% accuracy for most use cases)
• Support ticket volume (target: <5% of users per month)

Timeline and Staffing

The full journey from pilot to portfolio typically takes 12–18 months for a mid-market real estate business. Here’s what it looks like:

Stage	Duration	Team Size	Key Milestone
Pilot	8 weeks	3	Proof of business value
Hardening	8 weeks	4	Production-ready system
Expansion	10 weeks	3	5 teams/locations using system
Optimisation	26 weeks	3	20–30% cost reduction, improved UX
Scale	Ongoing	4	Portfolio-wide deployment, continuous improvement

Note: These timelines assume you’re working with a partner (like PADISO) to accelerate the process. If you’re building everything in-house, add 50% to each timeline.

---

Security, Compliance, and Audit Readiness

Real estate businesses handle sensitive data: tenant information, financial data, property details, transaction records. AI systems that process this data need to be secure and compliant.

By 2026, most enterprise real estate businesses will need SOC 2 or ISO 27001 certification. If you’re working with institutional investors or managing properties for large portfolios, you’ll need it sooner.

The Compliance Landscape for Real Estate AI

Real estate AI systems are subject to:

• Data privacy regulations: GDPR (if you have EU tenants), CCPA (if you have California tenants), various state and local laws.
• Fair lending laws: If your AI system screens tenants or evaluates creditworthiness, it must comply with fair lending laws (no discrimination based on protected characteristics).
• Cybersecurity standards: SOC 2 Type II (if you’re a SaaS vendor or manage data for others), ISO 27001 (if you’re managing sensitive data).
• Industry-specific regulations: Some states have specific regulations for property managers and real estate businesses.

Building Security and Compliance Into Your AI Operating Model

Don’t bolt security and compliance on at the end. Build it in from the start.

Step 1: Data Governance

• Classify your data (public, internal, confidential, restricted).
• Define access controls for each classification.
• Document where data comes from, where it goes, who can access it.
• Set up data retention and deletion policies.

Step 2: AI Model Governance

• Document the training data for each model (where it came from, how it was collected, potential biases).
• Test models for bias and fairness before deploying.
• Set up monitoring to detect bias or unfairness in production.
• Document model decisions and make them auditable.

Step 3: Infrastructure Security

• Use encryption in transit (TLS) and at rest (AES-256).
• Implement access controls (authentication, authorisation).
• Use a cloud provider with strong security (AWS, Google Cloud, Azure).
• Implement logging and monitoring (CloudTrail, VPC Flow Logs, application logs).

Step 4: Incident Response

• Document what happens if the AI system fails or produces bad results.
• Set up monitoring to detect anomalies or failures.
• Document who to notify and how to respond.
• Test incident response quarterly.

Step 5: Audit Readiness

• Use a tool like Vanta to automate compliance monitoring.
• Document everything (data flows, access controls, change logs, incident logs).
• Conduct annual security audits.
• Get SOC 2 Type II or ISO 27001 certification if you’re managing data for others.

Real Estate Compliance Example

Let’s say you’re deploying a tenant screening AI. Here’s what compliance looks like:

Data Governance

• Tenant data is classified as “confidential.” Only authorised property managers can access it.
• Screening results are classified as “internal.” Only the property manager and the leasing team can see them.
• Data is encrypted in transit and at rest.
• Data is retained for 7 years (per property management best practices), then deleted.

AI Model Governance

• The model is trained on historical screening data (with personally identifiable information removed).
• Before deployment, the model is tested for bias across protected characteristics (race, gender, national origin, etc.).
• In production, the model’s decisions are logged and auditable. If a tenant challenges a screening decision, you can explain why the model made that decision.
• Monthly, you review the model’s decisions to check for bias.

Infrastructure Security

• The screening system runs on AWS with encryption in transit (TLS) and at rest (AES-256).
• Access is controlled via IAM (Identity and Access Management). Only authorised users can access the system.
• All changes are logged in CloudTrail. All API calls are logged in application logs.
• The system is monitored 24/7 for anomalies or failures.

Incident Response

• If the screening system fails, a backup manual screening process kicks in.
• If the model produces biased results, the system is taken offline and the model is retrained.
• The leasing team is notified immediately if something goes wrong.
• Incidents are documented and reviewed monthly.

Audit Readiness

• You use Vanta to monitor compliance continuously.
• You conduct an annual SOC 2 Type II audit (if you’re managing data for institutional clients).
• You document all data flows, access controls, change logs, and incident logs.

If you need help getting audit-ready, PADISO’s Security Audit service can accelerate the process. They work with Vanta to get you SOC 2 and ISO 27001 ready in weeks, not months.

---

Measuring What Matters

AI projects fail because they measure the wrong things. They measure model accuracy when they should measure business outcomes. They measure activity (“we deployed 5 AI systems”) when they should measure impact (“we saved $500K annually”).

Your AI operating model needs clear measurement frameworks for each AI system.

The Three-Tier Measurement Framework

Tier 1: Business Outcomes What’s the business impact of the AI system?

Examples for real estate:

• Acquisitions: Deal velocity (days from lead to close), deal quality (ROI on acquired properties), acquisition cost (cost per deal)
• Property management: Tenant retention, maintenance cost per property, rent collection rate, days to fill vacancy
• Valuations: Valuation accuracy (actual sale price vs predicted price), pricing recommendations adopted, revenue from more accurate pricing
• Tenant screening: Screening time (hours saved per screening), screening cost (cost per screening), tenant quality (eviction rate, late payment rate)

For each AI system, define 1–3 business metrics that matter to the business. Measure them weekly or monthly.

Tier 2: Model Performance Is the AI system working as designed?

Examples:

• Accuracy: Valuation models: mean absolute percentage error (MAPE). Classification models (tenant screening): precision, recall, F1 score.
• Latency: How fast does the model produce predictions? Target: <100ms for real-time systems, <1 hour for batch systems.
• Throughput: How many predictions can the system produce per hour? Target: >1000 predictions/hour for most systems.
• Drift: Is the model’s performance degrading over time? Monitor weekly. Retrain if performance drops >5%.

For each AI system, define 2–4 model metrics. Measure them daily or weekly.

Tier 3: Operational Health Is the system running smoothly?

Examples:

• Uptime: Is the system available when users need it? Target: 99.9% for critical systems, 99% for non-critical.
• Error rate: What % of predictions fail or produce errors? Target: <1%.
• Cost: What does the system cost to run? (Infrastructure, vendors, support)
• Data quality: What % of data is complete and accurate? Target: >95%.

For each AI system, define 2–4 operational metrics. Measure them daily or weekly.

Measurement in Practice

Let’s say you’re deploying a valuation AI for residential properties. Here’s what measurement looks like:

Business Outcomes (measured monthly)

• Valuation accuracy: MAPE <5% (mean absolute percentage error)
• Pricing recommendations adopted: >70% of recommendations are used
• Revenue impact: $500K additional revenue from more accurate pricing (calculated as: # of properties valued × average price × margin improvement)

Model Performance (measured daily)

• Accuracy: MAPE <5%
• Latency: <100ms per prediction
• Drift: MAPE increase <5% month-over-month

Operational Health (measured daily)

• Uptime: 99.9%
• Error rate: <1%
• Cost: <$0.10 per valuation
• Data quality: >95% of required fields present

Every Monday morning, you review these metrics. If business outcomes are down, you investigate. If model performance is degrading, you retrain. If operational costs are spiking, you optimise.

Measurement Tools

You don’t need fancy tools to measure. A spreadsheet works. But as you scale, you’ll want:

• Monitoring and alerting: Datadog, New Relic, or cloud provider monitoring (CloudWatch, Stackdriver) to track operational health.
• Model monitoring: Evidently, Whylabs, or custom dashboards to track model performance and drift.
• Business intelligence: Tableau, Looker, or custom dashboards to track business outcomes.
• Data quality: Great Expectations or custom scripts to monitor data quality.

For a mid-market real estate business, start with cloud provider monitoring + custom dashboards in your data warehouse (Snowflake, BigQuery, Databricks). As you scale, add specialised tools.

---

Getting Started: Your First 90 Days

If you’re building an AI operating model from scratch, here’s a concrete 90-day plan.

Week 1–2: Assessment and Planning

Goal: Understand where you are and where you want to go.

Activities:

1. Audit current AI/automation: What AI systems or automation do you already have? What’s working? What’s not?
2. Identify pain points: What processes are manual, slow, or error-prone? Which ones have the highest business impact if improved?
3. Define governance: Who will make decisions about AI? Who will own the operating model?
4. Set objectives: What do you want to achieve in 12 months? (e.g., “reduce tenant screening time by 50%,” “improve acquisition speed by 30%,” “reduce property management costs by 20%”)

Deliverables:

• Current state assessment (what you have, what’s working, what’s not)
• Top 5 pain points ranked by impact and feasibility
• Governance structure (who decides, who’s accountable)
• 12-month objectives (3–5 concrete goals)

Timeline: 2 weeks, 1–2 people

Week 3–4: Pilot Selection and Planning

Goal: Choose your first AI project and plan it in detail.

Activities:

1. Evaluate opportunities: Using the build vs buy matrix, evaluate your top 5 pain points. Which ones are best suited for an AI solution?
2. Choose the pilot: Pick one high-impact, low-complexity problem. This should be something you can solve in 8 weeks with a small team.
3. Define success metrics: What does success look like? (Business outcome, model performance, adoption)
4. Plan the pilot: Who’s on the team? What’s the timeline? What data do you need? What tools will you use?

Deliverables:

• Pilot project charter (problem, success metrics, timeline, team, budget)
• Data inventory (what data do you need, where is it, how do you access it)
• Tool selection (what LLM, what platform, what vendors)
• Detailed project plan (weeks 1–8)

Timeline: 2 weeks, 2–3 people

Week 5–12: Pilot Execution

Goal: Build and deploy your first AI system.

Activities:

1. Set up infrastructure: Cloud account, data pipeline, development environment.
2. Prepare data: Extract data, clean it, prepare it for training.
3. Build the model: Train the model, test it, iterate.
4. Build the UI/UX: Create an interface for users to interact with the model.
5. Test with users: Get feedback from the actual users who’ll use the system.
6. Measure results: Track business outcomes, model performance, user feedback.

Deliverables:

• Working AI system (even if rough)
• Measurement dashboard (business outcomes, model performance)
• User feedback and learnings
• Decision: scale, pivot, or kill

Timeline: 8 weeks, 2–3 engineers + 1 product owner

Week 13–16: Post-Pilot Review and Decision

Goal: Review results and decide whether to scale, pivot, or kill the project.

Activities:

1. Review business outcomes: Did the AI system deliver the promised business value?
2. Review user feedback: Would users actually use this? What would make it better?
3. Review costs: How much did the pilot cost? What will it cost to scale?
4. Make a decision: Scale (move to hardening), pivot (change direction), or kill (move on to next project).
5. Plan next steps: If scaling, plan the hardening phase. If pivoting, plan the next iteration. If killing, plan the next pilot.

Deliverables:

• Pilot retrospective (what worked, what didn’t, why)
• Business case for scaling (if applicable)
• Plan for next 90 days

Timeline: 4 weeks, 2–3 people

Week 17–26: Scale and Hardening (if applicable)

Goal: Turn the pilot into a production-ready system.

Activities:

1. Harden infrastructure: Move to production infrastructure, add monitoring, add security.
2. Document everything: Write runbooks, documentation, training materials.
3. Test thoroughly: Unit tests, integration tests, user acceptance testing.
4. Get compliance sign-off: Security review, compliance review, audit readiness.
5. Train users: Train the team that will use the system.

Deliverables:

• Production-ready system
• Documentation and runbooks
• Monitoring and alerting
• Compliance sign-off
• Training materials

Timeline: 10 weeks, 3–4 people

Week 27–30: Expansion Planning

Goal: Plan how to expand the system to additional teams or locations.

Activities:

1. Identify expansion targets: Which other teams or locations would benefit from this system?
2. Plan customisation: What customisation will each team need?
3. Plan support: How will you support teams as they adopt the system?
4. Plan change management: How will you help teams transition to the new system?

Deliverables:

• Expansion plan (targets, timeline, team)
• Customisation framework
• Support plan
• Change management plan

Timeline: 4 weeks, 2–3 people

The 90-Day Rhythm

After your first 90 days, the rhythm changes:

• Weeks 1–12: Pilot a new AI system
• Weeks 13–16: Post-pilot review and decision
• Weeks 17–26: Hardening and expansion (if the pilot succeeds)
• Weeks 27–30: Planning the next pilot

Repeat this cycle every 90 days. By the end of year one, you’ll have 3–4 AI systems in production, a working operating model, and a clear path to scale.

Getting Help

You don’t have to do this alone. If you don’t have the internal capacity, PADISO can help. They can:

• Help you assess where you are and what to build first (AI Quickstart Audit)
• Help you plan your first 90 days
• Co-build your first AI system with your team
• Hand off to your team once it’s working
• Scale the system across your portfolio

Or if you prefer a fractional CTO approach, PADISO can provide strategic leadership while your team builds.

---

Wrapping Up: Your AI Operating Model in 2026

By 2026, the real estate businesses that win will be those with a working AI operating model. Not a collection of AI tools. Not a one-off pilot that never scales. A coherent, governed, measurable system for building, deploying, and iterating on AI.

That operating model rests on five pillars:

1. Clear governance and accountability — Someone owns each AI system. Someone is accountable for success or failure.
2. Modular architecture and data foundation — Your data is clean, organised, and accessible. Your AI systems plug in and out without breaking the whole stack.
3. Vendor agnosticism and build discipline — You build where you have competitive advantage. You buy everything else. You avoid lock-in.
4. Continuous measurement and feedback — You measure business outcomes, model performance, and operational health. You iterate based on what you learn.
5. Cross-functional delivery and iteration — Engineers work alongside operations teams. You move fast and iterate based on user feedback.

If you get those five things right, you’ll have a machine that compounds. Each AI system you build will be faster and cheaper than the last. Each system will create data and learnings that improve the next one. By the end of 2026, you’ll be running AI systems across your entire portfolio, and you’ll have a competitive advantage that’s hard to copy.

Start now. Pick your first problem. Assemble your team. Build your first pilot. Measure the results. Scale what works. Kill what doesn’t. Repeat.

The real estate businesses that are building their AI operating models today will be running on AI by 2026. The ones that wait will be playing catch-up.

Which camp will you be in?

---

Next Steps

Ready to build your AI operating model? Here’s what to do next:

1. Assess where you are: Run an AI Quickstart Audit to understand your current state, what to build first, and what 90 days could unlock. Fixed scope, fixed fee, two weeks.

2. Get strategic advice: Book a call with PADISO’s AI advisory team to discuss your 12-month plan, your first pilot, and how to avoid the common pitfalls.

3. Build your first system: Work with PADISO’s AI & Agents Automation service to co-build your first AI system with your team. They’ll hand off to your team once it’s working.

4. Scale with confidence: As you scale, use PADISO’s fractional CTO service to provide strategic leadership and architectural guidance.

5. Get audit-ready: When you’re ready for enterprise deals, use PADISO’s Security Audit service to get SOC 2 and ISO 27001 ready in weeks, not months.

Or explore PADISO’s case studies to see how other companies have built their AI operating models.

The best time to start was 12 months ago. The second-best time is now.