Legal Center
Privacy Policy
Komod reads leases, invoices and bank activity so a person can close the books with confidence. That work touches personal data. This policy says plainly what we collect, what we do with it, and what you can ask of us.
Last updated
Who we are
Komod is Komod.ai, Inc., a Delaware corporation. We run Komod.ai, an AI controller for commercial real estate: software that reads a customer's leases, invoices and bank activity, matches them to the customer's books, and drafts the monthly owner report for a person to review and approve. This policy explains what personal data we collect, why, and the choices you have.
Komod.ai, Inc.'s registered agent is Harvard Business Services, Inc., 16192 Coastal Highway, Lewes, Delaware 19958. Questions about this policy and requests about your data go to [email protected].
This policy covers our public website, the signed-in product, and the owner portal. Where a customer organization has connected its own systems to Komod, that customer decides what data those systems hold and why; we process it on the customer's instructions under our Data Processing Addendum.
What we collect
Account data
When a customer's administrator invites you, or you sign in, we hold your name, your e-mail address, a hash of your password, your role in the organization, and the organization you belong to. We record sign-ins, invitations, password resets and role changes on the organization's audit trail.
Customer data
Customer Data is everything a customer organization brings into Komod to run its close: the documents it uploads or that arrive in a mailbox it connects, the bank transactions and balances it connects, the chart of accounts and entries it connects from its accounting system, and the questions and instructions its people type in the product. Customer Data can contain personal data about tenants, guarantors, landlords, vendors and their staff, about the customer's own staff, and about the owners and investors who read the portal. The customer owns it and decides why it is processed.
The connectors read the following, and nothing more:
- Mailbox (Gmail, Microsoft 365 or IMAP) — the invoices and lease documents that arrive in the mailbox the customer connects, read when the close runs.
- Bank (through Plaid) — transactions and balances, read only; nothing is ever written to a bank.
- QuickBooks Online — the chart of accounts, vendors and journal entries; an entry is written only after a person approves it.
- Uploads — the leases, invoices, bank statements, check registers and spreadsheets the customer uploads by hand.
Usage data
In the signed-in product we collect how it is used: pages viewed, features used, the timing of each step, and errors. These events are tagged with an opaque user id, the organization id and your role. They carry no name, no e-mail address, no amount, no document and no typed value. Session replays are masked in your browser before they leave it: every text node, input and attribute is replaced, so a replay shows layout and navigation and nothing legible. Product analytics run only for signed-in users; the public pages collect none.
Support and correspondence
When you write to us, we keep the correspondence and what you tell us so we can answer and keep a record of what was agreed.
Website data
When you visit our public pages your browser sends the usual technical data — the address of the page, your browser type, and your network address — which our web server needs to answer the request. The public pages of komod.ai — the home page, the leakage methodology page, the sign-in page and every other public page — set no analytics cookie and load no analytics script. Product analytics (PostHog, masked session recording) run only after you sign in to the product, and only for the signed-in session. The public pages set no advertising cookie either. The only cookies Komod sets are the ones the signed-in product needs to keep you signed in and to run the masked analytics described above.
Why we use it
- To provide the service: read the customer's documents and feeds, match them, propose entries and questions, and draft reports for a person to approve.
- To keep accounts secure: sign you in, enforce your role, detect misuse, and record every act on the audit trail.
- To run the business: bill the customer's prepaid credits, answer support, and keep the records the law requires us to keep.
- To improve the product: read masked usage data to find what is slow, confusing or failing.
- To meet legal obligations and to protect our rights and yours.
Komod does not sell personal data, does not share it for advertising, and does not use Customer Data to build profiles of the people it describes.
Legal bases
Where the General Data Protection Regulation or a similar law applies, we rely on the following bases:
- Contract — to provide the service you or your organization signed up for, including account data and support.
- Legitimate interests — to keep the service secure, to prevent misuse, to improve the product from masked usage data, and to run our business, where those interests are not overridden by your rights.
- Legal obligation — to keep the records tax, accounting and company law require, and to answer lawful requests.
- Consent — where we ask for it, for example for optional communications. You can withdraw consent at any time.
For Customer Data, the customer organization is the controller and Komod is its processor: we act on the customer's documented instructions, and the customer's own lawful basis governs. Our Data Processing Addendum sets out those terms.
Where the California Consumer Privacy Act applies, Komod acts as a service provider for Customer Data. We do not sell or share personal information as those words are defined there, and we process it only for the business purpose of providing the service to the customer.
How the AI reads your data
Komod sends the text of a document, and the questions a user asks, to a foundation model to read, classify and draft. Every model we may call is developed by a company headquartered in the United States or the European Union and is served from an enterprise cloud there; no other model is used. Today those developers are:
- OpenAI — San Francisco, United States
- Anthropic — San Francisco, United States
- Google — Mountain View, United States
- Mistral AI — Paris, France (European Union)
Of these, only the developers named in the sub-processor table below receive Customer Data today; a developer is added to that table, with notice, before it does. Document text is sent to the model as data to read, never as instructions to follow. What the model produces is a proposal: an entry, a classification, a question or a draft. A person reviews it, and nothing reaches the customer's books until that person approves it. Every figure in a report links back to the transaction, lease clause, calculation or document it came from.
International transfers
Komod is a United States company, and the sub-processors above are headquartered in the United States. Personal data protected by European or United Kingdom law may be transferred to a country without an adequacy decision. For those transfers we rely on the European Commission's Standard Contractual Clauses, or the United Kingdom's addendum to them, as the transfer mechanism. The Data Processing Addendum sets out the details.
How long we keep it
We keep Customer Data for as long as the customer's agreement with us is in force. The customer's conversation history and audit trail are part of its auditable record and are kept whole; the platform never trims them.
When the agreement ends the customer has 30 days to export its data, and then we delete the live data. Backups expire on the normal rotation of seven daily, four weekly and three monthly sets. Komod keeps no separate archive of Customer Data.
Account data is kept while you have an account and for as long afterwards as we need it to meet legal obligations or resolve disputes. Masked usage data is kept in aggregate. Correspondence is kept for as long as we need it to answer you and to keep a record of what was agreed.
How we protect it
The measures below are the ones our Trust Center describes and our Data Processing Addendum binds us to. In short:
- Encryption in transit. Every connection to the service is over HTTPS. The public edge terminates TLS, sends HTTP Strict Transport Security, and forwards to services that listen on the loopback interface only — the application, the database, the object store and the queue publish no public port.
- Encryption at rest for connector secrets. The credentials that link a customer's QuickBooks, mailbox and bank to the service are stored under AES-256-GCM authenticated encryption with a fresh random nonce per value and a key ring that supports rotation; a re-encryption sweep moves every stored secret to the current key without downtime. Backups are encrypted with a public-key tool when a recipient is configured.
- Access control and roles. Access is by organization membership and role. The accountant role runs the close and administers the organization; the approver role decides the approvals put in front of it; the viewer and owner roles read the portal only and are refused on every other route. Only the accountant role can confirm an entry into the customer's books. Sessions are signed tokens that expire after twelve hours, and passwords are stored as bcrypt hashes.
- Tenancy isolation. Every record is scoped to the organization that owns it, and every read and write carries that scope. A record that belongs to another organization is answered as not found, never as forbidden, so nothing about it is disclosed. Komod's own operator console creates organizations, invites the first accountant and manages plans; it never reads a customer's documents, figures or conversations and has no way to sign in as a customer.
- Human approval on every posting. The service drafts. Every entry it proposes is put in front of a person to review, and only that person's click, in the accountant role, writes to the customer's books. No message typed into the chat can approve, post or pay.
- Model governance. Every model the platform may call is developed by a company headquartered in the United States or the European Union and served from an enterprise cloud there; the rule is enforced in code and no other model is used. Document text is sent to the model as data to read, never as instructions to follow.
- Logging and audit. Every act on the books, every approval, every connection and every sign-in writes one row to an audit trail that the platform only appends to. Conversation transcripts are kept whole and are never trimmed by the platform. Every response carries a request id so an event can be traced end to end. Logs redact credentials and encrypted values.
- Backups and continuity. A nightly job writes a complete set — the database and every stored document — with a manifest of checksums, encrypts the set before it leaves the server, copies it off-site to the storage named in the sub-processor table, keeps seven daily, four weekly and three monthly sets, and records its last successful run. The scheduled host health check reads that record, fails its unit when the last success is more than 36 hours old, and notifies executive leadership the same way every other failed unit does. Every scheduled operations unit on the host carries an automated on-failure hook, and a failed run sends a notification to executive leadership. A restore drill script restores a set from the server's local copy into a scratch database and a throwaway bucket and compares counts, so a restore is rehearsed, not assumed.
- Secure configuration. The production configuration is checked at start and refuses to run with a plaintext origin, a bare IP address or a wildcard cross-origin rule. The health endpoint says only whether the service is up and discloses no version. Browser pages carry a per-request Content Security Policy nonce, so an injected script does not run.
- Analytics minimisation. Product analytics run only in the signed-in product and identify a user by an opaque id, the organization id and the role — never a name or an e-mail address — and carry no amount, document or typed value. Session replays are masked in the browser before they leave: every text node, input and attribute is replaced, so a replay shows layout and navigation and nothing legible. The public pages set no analytics cookie.
Your rights
Depending on where you live, you may have the right to:
- know what personal data we hold about you and receive a copy;
- have inaccurate data corrected;
- have your data deleted, where we have no lawful reason to keep it;
- restrict or object to certain processing;
- receive your data in a portable form;
- withdraw consent where processing is based on consent;
- not be discriminated against for exercising a right;
- complain to a supervisory authority.
To exercise a right, write to [email protected]. We will verify that the request comes from you and answer within the time the applicable law allows. If your request concerns Customer Data — for example, a lease that names you — we will pass it to the customer organization that controls that data and help it respond, because the decision is the customer's to make.
Children
Komod is a business tool. It is not directed at anyone under eighteen, and we do not knowingly collect personal data from children. If you believe a child has given us data, write to us and we will delete it.
Changes to this policy
When we change this policy we update the date at the top and, for a change that affects how we use your data, we tell customers through the product or by e-mail before the change takes effect. Earlier versions are available on request.
Contact
Privacy questions and requests: [email protected].
Written notice to Komod under our agreements is given by e-mail to each of [email protected] and [email protected]; a notice sent to only one of them is not effective.
Komod.ai, Inc.'s registered agent is Harvard Business Services, Inc., 16192 Coastal Highway, Lewes, Delaware 19958.