There's a question that's easy to defer when you're first building a platform: where does each business's data live, and who's allowed to see it? Deferring that question usually means answering it later with a painful migration, once real customers are running on the real system.
One data space per business
Harnix separates tenant data at the storage layer, not with a tenant_id column
bolted on afterward and a hope that every query remembers to filter by it. Each
business gets its own data space for documents, agents, and conversation history.
End users only ever see their own conversations — not other users' in the same
organization, and certainly not another organization's.
Why it can't be added later
How a system stores data shapes how it can delete data. If tenancy is a filter condition added to each query, guaranteeing that a deletion removes exactly — and only — one user's data when they ask becomes a problem of auditing the entire codebase. If tenancy is a boundary at the storage layer, deletion is a local operation within that one data space.
This isn't purely a technical detail. Decree 13/2023 on personal data protection sets concrete requirements for deleting data on request. A tenancy architecture separated from day one is what makes answering that request reliable, instead of an unverifiable promise.