Full Visibility Into Every AI Request and Policy Decision

Governance without a record is just a set of promises. Visibility is what makes the promises provable.

In the previous three parts of this series, we covered how Arbitex routes every AI request, inspects it for sensitive data, and enforces the policies your security team has defined. Each of those stages produces an outcome. Visibility — Stage 4 — is where those outcomes become a record.

Not a log file someone has to parse. Not an aggregate dashboard that tells you traffic was “mostly compliant.” A complete, immutable record of every request, every detection, every policy decision, and every enforcement action — tied to a specific user, team, model, and timestamp.

This is the stage that answers the board’s question.

What “Immutable” Actually Means

The word gets used loosely. In the context of the Arbitex audit log, immutable has a specific technical meaning: each log entry is cryptographically linked to the entries before and after it. If any record is altered or deleted, the chain breaks, and the alteration is detectable.

No user — including account owners and administrators — can modify or delete audit log records. This is not a permission setting. It is a structural property of how the log is written. When a regulator asks for evidence that a policy was active and enforced during a specific period, the audit log is the evidence. Its integrity does not depend on trusting the people who operated the system.

This matters because regulated industries have specific requirements for log integrity. Healthcare organizations operating under HIPAA, financial institutions subject to SEC recordkeeping rules, and organizations in scope for PCI-DSS all face requirements that assume audit records are reliable. An audit log that can be modified by administrators is not a reliable audit record.

What Every Log Entry Contains

Every AI request that passes through the Arbitex Gateway produces a log entry. The entry contains:

• When — timestamp to the millisecond, UTC
• Who — the user and team that made the request, with their authenticated identity
• What — the model and provider the request was routed to, and the routing mode used
• Detection results — what the Protection pipeline found, if anything: the type of sensitive data, which layer detected it, and the detection confidence
• Policy decision — which policy evaluated the request, and what the policy said
• Enforcement action — what the gateway did: allowed, blocked, or redacted, and why
• Cost — the token count and cost associated with the request, attributed to the team and project

This is not a summary. It is a complete record of what happened and why, for every call.

Compliance Reporting Without Manual Assembly

For organizations subject to specific compliance frameworks, the audit log feeds directly into compliance reporting. When an auditor asks to see evidence that PII controls were active during a quarter, you do not need to assemble evidence from separate systems, log aggregators, and queries.

Arbitex generates compliance-mapped reports on demand. The report shows what was detected, which framework’s requirements were triggered, what action was taken, and the timestamp. Signed exports are available for submission to external reviewers or regulatory bodies.

The 12 compliance frameworks Arbitex ships with — including PCI-DSS, HIPAA, GDPR, GLBA, SOX, CCPA, BSA/AML, SEC Reg FD, FERPA, EU AI Act, NIST AI RMF, ISO/IEC 42001 — are mapped at the policy level. A detection that triggers a HIPAA-configured policy is logged with the HIPAA reference. The audit record already knows why something was blocked.

Dashboards for Day-to-Day Oversight

The audit log is the long-term record. For day-to-day oversight, Arbitex surfaces real-time dashboards that give security and operations teams visibility into what is happening now.

What those dashboards show:

• Request volume — total calls through the gateway, by team, model, and provider
• Detection rate — what percentage of requests triggered the Protection pipeline, and for what type of sensitive data
• Policy violations — how many requests were blocked or redacted, by policy and by team
• Spend by team and provider — live view of AI usage costs, with team-level breakdowns
• Provider health — status of each connected model provider, with latency and error rate

These are not vanity metrics. They are the operational view that lets a security team spot anomalies — a team suddenly making ten times their normal volume of requests, a spike in PII detections from a specific application, a provider with degraded performance before it becomes an outage.

For organizations already running observability infrastructure, Arbitex exports metrics via the OpenTelemetry standard, which means request data flows into whatever observability platform you already use.

The Question This Answers

The board question about AI governance is usually some version of: “Are our AI interactions governed? Can you prove it?”

The first three stages of the pipeline are what make the answer “yes.” Routing determines where requests go. Protection finds sensitive data before it reaches any model. Control applies the rules your team has defined. All of that is real governance.

Visibility is the proof. It is the answer you open when someone asks. It shows every request, every decision, every action — in a format that cannot be altered after the fact.

For a security leader, that is the difference between governance as a policy document and governance as an operational fact. Arbitex is built for the latter.

This concludes the “Inside the Platform” series. Each post covers one stage of the Arbitex pipeline:

• Routing — how Arbitex routes your AI requests →
• Protection — what happens to your data →
• Control — how Arbitex enforces your policies →
• Visibility (this post)

See the full audit log in a demo → Read about audit logging and compliance →