A lease is not just a document. It contains tenant identity, financial terms, social security context, security deposits, and legal positions. Uploading that to an AI tool transfers risk most landlords have never thought about, because the marketing around AI software talks about features, not about where the data goes. A lease that leaks into a training set can surface anywhere. A lease visible to the wrong person in a shared workspace is a conversation you did not choose. Before uploading anything, every operator should know five things about the platform.
Dwelon documents its isolation model and makes data boundaries part of the onboarding conversation.
The five questions
1. Where does the data go?
Is processing done in the vendor's own infrastructure or through third-party model APIs? If through third parties, which ones, under what terms, and are they trained on your data? The difference between "your data stays in your workspace" and "your documents pass through a general-purpose model service" is material. Vendors should answer this in plain language.
2. How is it isolated?
Tenant isolation matters at three levels: storage (your documents are separated from other customers' data), processing (your documents are not used to improve shared models), and access (who at the vendor can see your data, and under what conditions). The isolation model should be published, not discovered in a support ticket. Dwelon's security model is published for exactly this reason.
3. What is the retention policy?
When you delete a document, is it actually gone? From storage, from caches, from backups? What happens to your data when you cancel? Retention commitments should be written, specific, and enforceable. "We keep backups for 30 days" is a policy. "We respect your privacy" is not.
4. Who can access what?
Role-based access is the minimum: which of your team members can see which documents, and what the vendor's own staff can access for support or incident response. Least privilege should be the design, not a request. Access records should exist. If someone at the vendor opened a file, there should be a reason and a log.
5. What happens in an incident?
Breach notification timelines, encryption state (at rest and in transit), and the certification or audit evidence behind the claims. If the vendor cannot name the encryption standard, the certificates, or the notification commitment, the answer to every other question is weaker than it looks.
The realistic threat model
The realistic risks for a small operator are not nation-state adversaries. They are: documents leaking into model training and surfacing elsewhere; a shared workspace where the wrong person sees a lease; a vendor whose support staff browse customer data; and a retention policy that keeps data after the relationship ends. Each one is addressed by the five questions above, and each one is common enough in AI tooling that asking is not paranoia.
Why isolation is a feature, not a footnote
For property operations, data isolation is not an IT concern bolted onto the product. It is the property that makes other features safe to use. Lease analysis, tenant communication, and collection workflows all run on documents that must not leak. A platform that publishes its isolation model is structurally different from one that mentions the topic in a privacy policy. For how Dwelon positions the same discipline in its documentation, see the agent-facing security brief.
The checklist
Published isolation and processing model.
Written retention and deletion commitments.
Encryption at rest and in transit, named and verifiable.
Role-based access with least privilege.
Incident notification commitment and evidence.
If a vendor cannot answer all five in writing before you upload a single lease, that is the answer. Send the five questions before the first document goes up. A platform that answers them in writing, and publishes its model, is the one safe to build a workflow on.