Build AI on Your Data Model, Not Your Vendor's
On this page
Buying AI inside a point solution means adopting that vendor's data model — its entities, its hierarchy, its definitions. Your own enterprise data model, the one your warehouse program spent years building, is what encodes how your business actually operates. AI should run on top of that model, not replace it.
For most of the last decade, the serious data conversation in real estate was about foundations. Warehouse programs. Lakehouse migrations. Getting Yardi, RealPage, Entrata, work orders, surveys, and the general ledger into one place with one definition of a property, one definition of a portfolio, one definition of a resident. Slow, expensive, unglamorous work — and the right work.
Then AI arrived, and a lot of that discipline went out the window. I spend my time with COOs and CIOs who have a dozen AI experiments running and no platform, and the pattern repeats: the leasing team bought an AI assistant, resident services bought a second one, the maintenance vendor shipped a third in a product update. Each of those tools is genuinely useful in its lane. And each one quietly asked the company to hand over the thing it spent years building — the model of its own business — in exchange for a feature.
That is the trade nobody prices. Here is how to see it, and how to avoid it.
Why buying AI from a point solution means adopting its data model
Every application ships with an opinionated schema, and the AI inside it can only reason about the objects that schema defines.
A leasing AI thinks in leads, tours, and conversations. A maintenance AI thinks in work orders, techs, and SLAs. A CRM thinks in contacts and stages. Those are reasonable primitives for the job each tool was built to do — but they are that vendor's primitives, designed for the average of their customer base.
Your data model contains things theirs does not: the asset-level distinctions your investment committee actually uses, your fund and joint-venture structures, your regional groupings that do not match anyone's org chart, your renovation tiers, your definitions of a stabilized asset or an at-risk community, the operating standards that make your platform different from the operator down the street. That model is your operating model, written down. It is the reason two owners with identical unit counts perform differently.
When AI lives inside a point solution, none of that exists. The AI is bright and completely uninformed about how your company sees the world.
What you lose when the vendor's data model wins
Three things, in escalating order of cost.
- Resolution. Your entities get flattened into theirs. A question like "how are our value-add assets in their second renewal cycle performing against the stabilized set?" is not hard because the data is missing — it is hard because the tool has no concept of "value-add" or "second renewal cycle." Your distinctions vanish at the boundary.
- Compounding. Every workflow you build inside a point tool is built on that tool's objects, so it cannot be reused anywhere else. Ten tools, ten sets of logic, none of them additive. Meanwhile the warehouse — the one asset that would compound — sits underneath, feeding dashboards.
- Optionality. This is the expensive one. Once your workflows are expressed in a vendor's schema, your roadmap is their roadmap. You can only automate what they have decided to expose. And you cannot leave without rebuilding, which is exactly why the schema is designed that way.
That is the handcuff. Not a contract term — an architecture. It is also how AI vendor sprawl turns from an annoyance into a structural problem: each tool takes a piece of your operating model with it.
Who owns the data in an AI platform?
Ownership has three separate questions inside it, and vendors are usually only clear about the first one.
- Who owns the records? Almost always you. This is the easy answer, and it is in every contract.
- Who owns the model — the entities, relationships, and definitions? This is the one that matters, and it is frequently the vendor. If the platform can only represent your business using its own object types, you own the rows but not the meaning.
- Who owns the derived layer — the enrichment, the scores, the classifications, the conversation context the AI generates? Ask explicitly. Ask whether it is queryable, exportable, and traceable back to a source record. If the intelligence your operation generates can only be viewed inside the vendor's interface, you are renting your own history.
A short version to take into a vendor call: if the platform cannot represent an entity that exists in your business but not in their product, they own the model, not you.
Build vs buy: do you have to build your own AI?
No — and this is where the argument usually goes wrong.
The instinct after this diagnosis is to build in-house, because building is the only way most teams have seen to keep control. But building a durable AI platform means owning orchestration, retrieval, evaluation, permissioning, model churn, and safety — permanently, with a team that competes for talent against every AI lab. Very few operators want that to be a core competency, and the ones who try usually end up with a good prototype and a stalled program.
The real choice is not build vs buy. It is which layer you buy at.
Buy at the point-solution layer and you buy a schema along with the feature. Buy at the platform layer and you buy infrastructure — orchestration, governance, security, integration — that maps onto the model you already own. Same procurement process, opposite outcome for optionality.
The evaluation question that separates the two: "Can we define a new entity, workflow, or metric that your product has never seen before — and can our business users do it without your engineering team?" If the answer needs a roadmap conversation, you are buying at the wrong layer. It belongs on the shortlist of questions in any enterprise AI platform evaluation.
How to unlock data trapped in your PMS and CRM
You do not move it. You put a context layer above it.
The systems of record stay exactly where they are — Yardi, RealPage, Entrata, AppFolio, your ticketing system, your survey tool, your warehouse. The platform layer connects to them and holds the thing none of them individually has: a unified model of your company, portfolios, communities, units, residents, and the operational events that connect them, expressed the way your business defines them.
That is the difference between an AI that can answer "how many open work orders are there?" and one that can answer "which communities are showing maintenance and sentiment patterns that put renewals at risk next quarter?" The second question is not a harder model problem. It is a data-model problem — it requires a system that knows those objects are related in your business, because your model says so.
Three practical rules if you are building this layer:
- Do not wait for perfect data. Start with the systems you have access to and expand. Teams that hold the AI program until the warehouse is finished ship nothing for two years — the point clean data alone was never going to solve.
- Keep the semantic definitions in your control, not in a vendor's configuration you cannot export.
- Insist on lineage. Every AI answer should be traceable to the source record it came from. Explainability is not only a compliance requirement — it is how the business learns to trust the output.
How Travtus approaches this
Travtus is built as the Everyday AI™ Platform — enterprise infrastructure that sits above your systems of record rather than replacing any of them. The platform integrates with the stack you already run and builds a context layer over it, so the AI reasons about your company the way your business defines it: your portfolios, your hierarchy, your operational reality. No rip-and-replace, and no schema surrender.
That is the deliberate design choice behind everything else. Because the context layer belongs to you, the workflows built on it belong to you too — they are not trapped inside one department's tool, and they compound instead of fragmenting. Explore, our conversational layer over that context, exists for the same reason: business users get answers from the model directly, without an analyst in the middle, and customers see around a 15% productivity improvement simply from making information easier to reach.
Your data model stays yours. The AI is what you build on top of it.
Frequently asked questions
Who owns the data in an AI platform? You should own three things: the source records, the data model itself, and the derived intelligence the platform generates. Contracts usually cover the first and stay vague on the other two. Ask specifically whether enrichment, scores, and classifications are exportable and traceable to their source — if they are only visible inside the vendor's interface, you do not functionally own them.
Should we build our own AI platform or buy one? For almost all operators, buy — but buy at the platform layer, not the point-solution layer. Building means permanently owning orchestration, evaluation, security, and model churn. Buying at the platform layer gets you that infrastructure while keeping your own data model, which is the part that actually differentiates your business.
How do we unlock data trapped in our PMS and CRM? Add a context layer above the systems of record rather than migrating out of them. The platform connects to your existing systems and unifies them into one model of your business, so AI can reason across sources. You get cross-system answers without a rip-and-replace or a two-year migration.
Can an AI platform work with our existing data warehouse? It should complement it, not compete with it. Your warehouse is the governed foundation; the AI platform is the layer that reasons and acts on top of it. Ask any vendor how their platform reads from your warehouse, whether derived outputs can flow back into it, and how lineage is preserved in both directions.
What is the difference between an AI platform and an AI point solution? A point solution automates one task inside one department, using its own data model. A platform provides shared infrastructure — context, governance, orchestration — that multiple departments build on, using yours. The practical test: a point tool's workflows cannot be reused outside it, while a platform's compound across the business.
Want to see what this looks like on your stack? Talk to Travtus about where the context layer would sit — bring the systems you run today and the questions your team cannot currently answer.
