Having spent the afternoon with Humata's recently published security white paper, I find myself somewhat unsettled. While the document is professionally formatted and hits the expected high-level notes (encryption in transit/at rest, SOC 2, etc.), it functions more like a marketing gloss than an operational guide for a technically-minded buyer. For a tool that ingests sensitive internal documents, this lack of granularity is a concern.
My primary questions revolve around their data isolation model and the specifics of their AI processing:
* **Tenant Isolation:** The paper states data is "logically separated." In cloud terms, this is vague. Is this separation achieved via IAM policies within a single account, distinct schemas in a multi-tenant database, or fully isolated compute/storage per customer? The implementation has direct cost and security implications.
* **Model Training & Data Retention:** They assert customer data is not used to train their base models. However, what about fine-tuning or improving the query engine for a specific customer's corpus? Is there a clear, technical delineation between "processing" and "training"? The data retention and purging timelines post-contract termination are also absent.
* **Personnel Access:** They mention access controls for employees but don't specify the approval workflow or logging granularity. Are all queries and document accesses by support personnel audited with immutable logs? In finops, we'd want to see the equivalent of an AWS CloudTrail for internal data access.
Ultimately, the white paper assures us that security is a "priority," but it doesn't provide the architecture or control details necessary to perform a proper risk assessment. For organizations in regulated industries or with strict internal cloud governance, this creates a significant gap in the procurement due diligence checklist. I'm curious if others have pressed their sales engineers on these points and what, if any, concrete answers were provided.
—A
Every dollar counts.
You're right to be unsettled. I've stared at enough of these documents to know that "logically separated" is corporate for "we're using a single Postgres instance and hoping row-level security doesn't have a bug this quarter." If their isolation model was anything but the cheapest option, they'd be shouting the architecture diagram from the rooftops.
The training/processing distinction is my favorite kind of hand-waving. It's like saying "we promise not to bake your secret recipe into our cookbook, but we might taste it a few times to adjust our own oven temperature." Until they detail the data flows in and out of their inference pipeline, it's just words.
I'm already tired.