Transparency is only worth something if it is built out of mechanisms rather than intentions.
A black box asks you to accept a conclusion. A glass box hands you the working. The difference matters because the person who has to answer the regulator, the client questionnaire or the board is not us. It is you, and you cannot answer from somebody else's certificate.
Nothing forces an AI product to be a black box. Multi-tenant architecture, a shared data plane and an opaque price make the vendor's economics work, and each of them is a legitimate choice. But together they mean that when your security review asks where content goes, the only available answer is a summary written by the supplier, backed by an auditor's report about the supplier's controls.
That report describes their organization, not your obligation. A compliance obligation is not satisfied by somebody else's certificate. So the interesting question is not whether a vendor is trustworthy. It is what you would be able to demonstrate, in your own words, six months after you said yes.
| The question you will be asked | A black box answers | A glass box answers |
|---|---|---|
| Where does our content sit at rest? | ✕In the vendor's environment, described | ✓In the account you own, and you can look |
| What policy applied to that answer? | △A policy page, current version only | ✓A pinned, numbered content-policy version |
| Who could read it, and did they? | △Vendor staff, per the vendor's process | ✓Your roles and grants, with access written to the audit record |
| What is not yet closed? | ✕Not published | ✓Standing exceptions shown to you inside the product |
| What does the compute actually cost? | ✕A per-seat price with the margin inside it | ✓Your provider's invoice, addressed to you |
The left column is the category, not a particular product: a SaaS AI assistant, a bundled suite copilot, an enterprise search product. Several of them are good software. The distinction here is architectural, not a judgment about quality.
Visibility is not a document we send you. It is four mechanisms, each of which would be difficult to fake and easy for you to check. One organization sits in one cloud account, which the organization owns and is billed for directly. Client isolation is the account itself, not a row in a shared table.
Most AI pricing is a per-seat figure with an unknown amount of compute margin inside it, which is why nobody can tell you what a heavy user costs or what a quiet month saves. We took the opposite position, and it constrains us more than it constrains you: your cloud provider bills you directly, at their list price, and we never sit in that path. There is nothing there for us to mark up because we are not in it.
What we charge is a fee for the service. What the compute costs is between you and the provider whose invoice you already receive. That also means a quiet month is genuinely a cheaper month, which is not true of a seat.
What we have seen on real cloud bills, not a quote. The last figure is an estimate for a question of roughly 10,000 tokens in and 1,000 out at a mid-tier frontier model's list price. Your own usage decides your bill, which is the point. How compute costs behave.
Usage is metered per person and settled against the provider's own record of each call rather than an application counter, with per-person token quotas that fail closed. The product holds tokens, never currency. Metering covers the deployment's home region, and a settlement that fails deliberately overstates rather than understates consumption.
Not hosted by us with your name on it. The deployed platform and its data sit in the account you own and are billed for. If the relationship ends, that does not change, because there is no switch on our side that turns it off. You lose us, not the platform.
At the entry posture no cross-account role for us exists at all. On the higher tiers our management access is scoped and session-capped, and it is something you grant rather than something the architecture assumes. A supplier's standing access into a client account should be a decision, not a default.
It's not a black box. You can see how it's set up, and that's exactly what lets you answer for it.The line this page exists to defend
If a sentence cannot survive that question, it does not ship. In practice the test does most of its work by deletion: it removes the comfortable claim, the rounded-up number, the capability that is real in a demo and thin in production.
No. What is visible is the architecture, the controls and the exceptions, which is what a reviewer needs. Credentials, keys and content are not part of that set. A design whose safety depends on nobody understanding it is not a design, and the strongest controls here are the ones that hold precisely because they are enforced by cloud identity policy rather than by obscurity. What is enforced as a deny.
It is a claim about billing, so check it the way you would check any billing claim: the account is in your name and the provider's invoice comes to you. We never receive it. That is the whole mechanism, and it is verifiable on your first statement rather than on our word.
Our own, which is also the demo. It runs the same codebase from the same factory, so what you see is the product rather than a staged environment. Open the demo. A client deployment is theirs to show, not ours.
The inside of the model. We can tell you which model ran, under which content policy, in which region, for which person, and what it cost. We cannot tell you why a language model produced one sentence rather than another, and nobody can. That is one reason we are careful about which work belongs to inference at all. Where AI does not belong.
The assessment ends with a picture of how a deployment would sit in your environment, which is the first thing you would have to be able to explain.