Designing the Trust Layer for Brazil's
First Government-Scale AI Audit Platform

Status: Shipped government-scale AI/ML platform, designed and launched in 2017-2018.

Daniel's exact role: Sole Product Designer embedded at TCU, responsible for discovery, workflow architecture, structured input design, verification and correction surfaces, and auditor validation with live cases.

Why it matters for the target audience: This proves I was designing AI trust problems at institutional scale before "AI trust UX" became a hiring category. The LLM era changed the interface pattern, not the core problem: users must act on outputs they cannot fully verify unless the product makes verification possible.

Strongest outcome: 63% reduction in Audit Instruction writing time, 64% audit-cycle compression, 90% downstream rejection reduction, and 100% voluntary pilot adoption.

Impact caveat: Keep the metrics tied to the pilot/post-launch reporting language already present in the project data; do not overstate them as Daniel-only causal proof.

I didn't start with interface sketches. I started by getting in the room.

Laís (PO) and I ran multiple workshop series across both groups. We sat at auditors' desks. Watched them open active cases. Timed where they stopped, hesitated, switched windows, or reached for a Post-it. We used facilitated techniques — 5 Hats analysis, Lightning Decision Jams, dot-voting — not because the methods were magic, but because people who live inside a broken system for years stop seeing the breaks. Structured provocation makes the invisible visible.

By the end of the discovery series, we had catalogued over 60 distinct pain points. Three patterns cut across everything:

The transcription trap. Auditors spent the majority of writing time copying data they already knew existed in government databases — they just couldn't access it from within their workflow.

The legal citation minefield. Audit Instructions required precise citations to specific articles of multiple federal regulatory frameworks. A wrong article number, even with correct intent, triggered rejection.

The invisible queue. Cases were processed chronologically. A R$20,000 irregularity got the same queue position as a R$25M one.

These three patterns became the real design brief. Every product decision we made traces back to one of them. The workshop process also produced something harder to quantify: by the time we were building prototypes, the auditors were bringing their own live cases to test against. That shift — from skeptical subjects to invested co-designers — is why we hit 100% voluntary adoption at launch.

The existing Audit Instruction template (the Modelo Esquemático — the TCU's formal legal scaffold for accountability case write-ups) was a pre-existing document, not a design artefact. My contribution was adapting it.

Working session by session with the pilot auditors, I decomposed how expert legal minds actually structure their reasoning — what they decide first, what depends on what, where they need flexibility and where precision matters. Then I re-encoded that reasoning into structured, validated input fields the ML could read consistently.

The key design question wasn't "how do we display AI output?" It was: what structure does a human expert use when they think about this problem, and can we make that structure machine-legible without stripping the auditor's judgment?

This is the move that changed everything downstream. Clean, structured inputs meant the ML's outputs were more predictable. More predictable outputs meant auditors could verify them faster. Faster verification meant trust.

Four interaction decisions defined the platform. Each one removes a specific source of distrust — from the data layer upward to the correction surface.

Structured inputs before generated outputs. I adapted the formal Audit Instruction template into validated fields so the ML received more predictable, machine-legible inputs.

Clause-level verification instead of document-level trust. Every generated legal clause had to expose its source law, article, or precedent before an auditor could accept it.

Right-to-correct as architecture. The workflow preserved expert judgment through editable clauses, rich text, and explicit review states instead of forcing an approve/reject binary.

Priority by public accountability risk. The queue surfaced fiscal exposure and program scope, not just chronological order.

Live-case validation. Workshops moved from abstract exercises to auditors testing the system against active cases, which changed skepticism into adoption pressure.

A free-form AI draft generator. It would have looked impressive in a demo but failed the legal verification burden of real audit work.

A black-box confidence score. Confidence without inspectable evidence would have shifted risk onto auditors without giving them real control.

Chronological queue plus manual escalation. That preserved the existing priority debt and required humans to remember which cases mattered most.

End-of-process validation. Catching errors after weeks of work was the failure mode we were replacing.

Static Word output as the main deliverable. It would have recreated the old document workflow instead of turning the system into a shared, stateful workspace.

Shipped/prototype boundary: e-TCE shipped into production at TCU. It is not a concept case study.

Technology boundary: This was a 2017-2018 ML-assisted audit platform, not a modern LLM product. The relevance is the trust architecture: structured inputs, verifiable outputs, correction rights, and expert adoption.

Impact caveat: The outcome metrics belong to the shipped pilot/platform context and should remain framed as project/pilot outcomes, not solo-designer causal claims.

What I would improve now: Add richer trust-calibration telemetry, expose source confidence and uncertainty states more explicitly, instrument correction patterns, document governance decisions, and create a public technical appendix showing the state model, validation rules, and handoff logic.

During the final validation session, the Secretariat Director — a highly traditional and deeply skeptical legal authority — sat down to test the platform. He entered an active case's parameters into the input console. The AI generated the draft.

I watched him read it once, knit his brows, and open the source citation drawer. He cross-verified the references. He read it a second time.

This draft is better structured than what most of our junior auditors write after three weeks of work. It has captured the exact legal nuance I was looking for. This will turn months of my life into a single afternoon.

This was trust calibrated — not through blind faith, but through a transparent, inspectable, and correctable architecture.

The platform shipped into production. It was recognised by the Ministry as one of the year's landmark projects and added to the TCU institutional roadmap for expansion across all Secretariats. Post-launch data from the pilot Secex-TCE team: 63% reduction in Audit Instruction writing time · 64% compression of the audit-to-judgment cycle (5.5 years → ~2 years) · 90% drop in downstream rejections.

What this project proved

Input shaping beats output fixing. The cleanest way to fix an AI's output is to build an interface that structures how it receives the input. Verifiability is not a feature — it's the architecture. For high-stakes AI work, interactive fidelity of the trust mechanism is non-negotiable in prototype testing. A static mockup of an unverifiable AI output is functionally indistinguishable from a broken one.

The same upstream instinct — structure what the model receives, make what it produces inspectable and correctable — is what I apply to LLM interface design today.