Trade-offs in transparency
Transparency is not a free dial we turn to maximum. Pushing it too far in one dimension reduces it in another. A wall of explanation drowns the user. A fully disclosed threshold guides an attacker. An interpretable model is often the wrong model for the task. This section names the five trade-offs we make on purpose and how we resolve each one.
Context
Section titled “Context”A common failure pattern in AI governance is to treat transparency as monotonically good. In practice every transparency choice has a cost. To latency, to security, to attention, or to model quality. Our position. Transparency is necessary and bounded. We disclose where the user benefits from disclosure. We hold back where disclosure would harm them.
Performance vs explainability
Section titled “Performance vs explainability”The strongest models for our language tasks are large transformers with no classical explanation method. The models which are explainable by design (linear regression, decision trees, generalized additive models) perform materially worse on document extraction and natural-language reasoning.
How we resolve it. We use the strongest model for the heavy lifting and require grounded reasoning as a proxy for explanation. Every consequential output cites its source. A citation is not a full explanation, but it is a claim the user verifies, which is what an explanation needs to be in practice.
Security vs disclosure
Section titled “Security vs disclosure”Some details, if disclosed, give attackers an advantage:
- Exact anomaly-detection thresholds tell an attacker how to stay below them.
- Confidence calibration internals are used to build input which bypasses the threshold.
- System prompt contents enable prompt-injection attacks.
How we resolve it. We publish the categories of signals the AI uses and the general shape of its thresholds. We do not publish the specific numeric thresholds. We disclose the existence of a system prompt. We do not disclose its text. This is the line between behaviour transparency (in) and implementation transparency (out).
Too much transparency becomes noise
Section titled “Too much transparency becomes noise”If we surfaced every metric, every confidence score, and every reasoning trace for every transaction, users would be overwhelmed. Information overload is a disguised form of opacity. The important signal hides behind the unimportant.
How we resolve it. We layer disclosure. The default UI shows the confidence indicator and a “Why this?” link. The user clicks to dig deeper. Notifications fire only when they are actionable. HITL queues, anomalies, low confidence. Daily summary replaces individual notifications for routine activity.
Privacy vs explainability
Section titled “Privacy vs explainability”A detailed explanation for one transaction would leak information about another. If the AI’s reasoning compared this transaction to a baseline derived from other tenants, surfacing the comparison would expose cross-tenant patterns.
How we resolve it. Explanations contain only the querying tenant’s data. PII inside an explanation is redacted using the same rules as the input pipeline. Cross-tenant insights are presented as aggregate statistics, never as individual examples.
Speed vs detail
Section titled “Speed vs detail”Detailed explanation increases response latency. In a real-time chatbot, latency is a usability constraint, not a nicety.
How we resolve it. The default is a short, in-line explanation. Full detail is available on demand through “Show details” or through the Explanation API. Latency-sensitive paths emit minimal explanation synchronously and the full trace asynchronously.
What we tell customers about the limits
Section titled “What we tell customers about the limits”We disclose the limits of transparency directly:
- Some AI decisions have clear textual explanations. Others have only proxies (citation, confidence, comparable cases).
- Transparency does not replace testing. Customers pilot AI features before broad rollout.
- Transparency does not replace HITL. No explanation, no matter how well-written, makes the AI immune to error.