AI in building management: what it does and what it should never do

Which chores does AI remove today?

Strip away the marketing and the useful work is narrow and specific. In Domera, as of this writing, it is the following — and we would rather list six real things than promise a dozen vague ones:

• Reading a supplier invoice — uploaded or photographed — into a draft expense: vendor, net, VAT, gross, invoice date and due date, so the manager checks eight fields instead of typing them.
• Reading IBAN and BIC from a bank certificate, and contact details from a business card, without retyping.
• Reading contracts, insurance policies and inspection certificates for their key dates and amounts, so a renewal date or a compliance due date starts from the document rather than a guess.
• Parsing the free-text description on an imported bank statement line to suggest which owner and unit a payment belongs to.
• Flagging out-of-pattern items on the dashboard: an invoice well above the vendor's norm, a possible duplicate, a drop in collections, money that arrived unexpectedly.
• Answering questions about your own data — this building's balance, that owner's arrears, which certificates expire this quarter — through the Domera assistant, which reads the company's records and nothing else.

Each of these produces a draft or a suggestion. None of them posts anything. The invoice is drafted as an expense awaiting approval; the bank line carries a suggested owner until someone accepts it; the certificate dates sit in a form for a person to check against the paper. Our document and banking extraction page shows what the fields look like.

Why must a person confirm before anything is posted?

Because extraction is good, not infallible, and the cost of a wrong posting in a building ledger is not one wrong number — it is that number allocated across twenty owners' statements. The typical extraction errors are quiet ones: a gross amount read as net, an invoice date read as the due date, a credit note read as an invoice, the same invoice uploaded twice from two inboxes. A person who glances at the preview catches these in seconds; a system that posts automatically distributes them.

So the rule in Domera is mechanical, not a policy statement. Every extraction produces a draft that a person reviews and saves. The Domera assistant can read across the company's data freely, but the three things it can write — create a draft expense, record a payment, approve an expense — each return a preview and run only when the user confirms it. When they do run, the audit trail marks the entry as AI-initiated, so an auditor or a committee can later see which postings began as a chat instruction and who confirmed them. The same principle governs compliance: extraction can propose the dates from an inspection certificate, but it never records the inspection itself — a person does, because recording an inspection advances the next due date.

What should AI never decide?

There is a category of decision that belongs to people not because the software cannot compute it, but because the authority to make it sits somewhere specific — in the regulations, the general meeting, the committee, the law:

• The allocation method. Whether the lift is split by share or excludes the ground floor is fixed by the deed, the regulations or a vote. Software applies the rule; it must not choose it.
• Approving an expense on its own. Approval locks the allocation and puts charges on owners' statements; a person must do it.
• Sending communication to owners unreviewed. A reminder or notice that goes out with a wrong amount or the wrong tone damages trust for a year. Domera does not draft owner letters today; if it ever does, they will be drafts.
• Replacing the general meeting. Votes, quorum and resolutions are the owners' act. Software records them; it does not take them.
• Escalating arrears. Whether to refer a neighbour's debt to a lawyer is a minuted committee decision, not a threshold in a settings page.
• Interpreting the law. An assistant can find the clause in the regulations you uploaded; it cannot tell you what a court would make of it.

None of this is a limitation to apologise for. A committee that can say to its owners "the software drafts, a named person approves, and every approval is logged" has a stronger position than one that cannot explain how a charge came to be posted.

What does "out of pattern" mean, and what is it not?

The exception feed on the dashboard compares each new item with the history it belongs to — this vendor's previous invoices, this building's usual collections — and surfaces the ones that stand out. An invoice well above the vendor's norm, an amount and reference that match one already recorded, a month in which collections fell, a payment from an account nobody expected.

It is a prompt to look, not a verdict. The annual insurance premium is always "well above" the monthly cleaning invoice from the same broker; the first invoice from a new contractor has no norm to compare against; a genuine one-off repair is out of pattern because it is a one-off. Treat the feed as a reading list for the morning, work through it, and dismiss what is explained. Its value is that the unexplained duplicate gets seen before it is approved, not that it knows fraud when it sees it.

How does the assistant handle owners' data?

The assistant answers only from the company whose user is asking, with the same access limits that user has — a manager assigned to six buildings gets answers about six buildings. That is enforced by the database's row-level security and by explicit checks in the tools the assistant calls, not by asking the model to be discreet. Requests are rate-limited, and the assistant is a tool for the manager or committee, not a channel to owners: an owner-facing assistant that explains a statement in the owner's own language is an idea we think is worth building, and it is not built.

Two candid notes. First, the model behind the assistant is a general-purpose hosted model — currently a Google Gemini model — chosen for cost and speed and configurable by us. Ask any vendor, including us, to state in writing how your documents and data are used by their model provider. Second, a conversational interface makes it easy to ask "post that" — which is exactly why the write actions insist on a preview and a confirmation every time, however routine the request.

What should you ask a vendor?

Whichever software you are considering, these questions separate a drafting tool from a black box. Ask for the demonstration, not the slide:

• Which actions can the software's AI features take with no person confirming? Show me the list.
• Show me the preview step for an extracted invoice, and show me what happens when I correct a field.
• How does the audit trail mark an entry that began as an AI suggestion, and who is recorded as approving it?
• Where do uploaded documents go, who processes them, and are they used to train models?
• What happens when extraction is wrong — how do I fix it, and does the wrong value ever reach an owner's statement?
• Which languages does document reading handle? Our invoices are in Greek and English.
• Can we turn it off, per feature, and keep working?

A vendor whose answer to the first question includes "post", "send" or "approve" without a person in the sentence is asking you to trust a model with your owners' money.