Every software company that touches sensitive data says the same sentence at some point in the sales conversation: we don't look at your data. The sentence is usually true. The problem is not the honesty of the person saying it, it is that the person hearing it has no way to verify it.
This series starts here because this is the first question in every Aptabit evaluation, and because the answer says more about how the product was built than any list of features.
The difference between a promise and a consequence
When a SaaS vendor says it does not look at your data, it is describing a policy. The data sits on their infrastructure. Their team does, technically, have access to the database. What prevents access is the combination of contract, internal controls, auditing and the reputation the company would lose by breaking it. That is not nothing, but it is a promise: it depends on someone continuing to keep it.
There is a second category of answer, and that is the one that matters here. When the software runs inside the client's own infrastructure, the same sentence stops being a policy and becomes a description of what is possible. There is no database of ours holding your documents. There is no console from which our team queries your knowledge base. Not because we forbid it, but because that console would have to cross your network to exist at all.
The useful question, then, is not "do you look?". It is "what would you have to do in order to be able to look?". If the answer involves an internal decision by the vendor, it is a promise. If it involves the client granting access that does not exist today, it is architecture.
Where this stops being absolute
A series that only presented the favorable side would be worth nothing. There are at least three situations where the separation above gets less clean, and they are worth knowing before signing anything, with Aptabit or with any other vendor.
Support. When something breaks and you open a ticket, somebody needs to see enough to diagnose it. That access should not be permanent or implicit. It should be granted by you, with a scope and an expiry, and it should leave a record. The question to ask is how the vendor does support, not whether it does.
Cloud models. The platform runs local models and also knows how to talk to third-party models. If you point a flow at an external provider, the content of that flow leaves your network, and that provider's policy applies instead of ours. That is a legitimate choice in many cases and a terrible idea in others. What the platform does is make the choice explicit, flow by flow, instead of deciding for you.
Updates and telemetry. Software that never talks to its vendor also never receives a security fix. What matters is what travels through that channel. Operational metrics and version checks are one thing. Document content is another. Ask for the list.
What to ask any vendor
Regardless of whether the answer leads to Aptabit or somewhere else, these questions separate the two kinds of answer well:
- Where is the data physically stored and processed, including the embeddings and the search indexes?
- What exactly would the vendor have to do to read one of my documents, and would that leave a trace in my environment?
- Is support access permanent, or granted case by case?
- Which calls leave my network in normal operation, and what travels inside them?
- If the contract ends tomorrow, what keeps working and what stops?
The fifth is the most uncomfortable, and it is the subject of a later piece in this series.
Why this is the first piece
The opening line of our site says that the data that matters most is exactly the data you can't send. That is not a marketing provocation, it is the description of a real deadlock. The sources that would solve an organization's most expensive problems, the contract history, the technical reports, the operational records, the case files, tend to be exactly the ones that are not allowed to leave. An AI that only works when the data leaves never reaches that material.
Going to the data, rather than asking the data to come to us, is the decision that organizes everything else in the product. The next pieces in this series deal with the consequences of it, including the inconvenient ones.