- Every automated decision stored with model version, inputs used and reason codes
- Customers given clear reasons and a route to request human review
- Reviews handled in a workbench with the full decision context
- Models released through a governed gate with performance and stability checks
- Data used for credit decisions documented and minimised
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A digital lender in Brazil offered personal loans and credit lines through its app. Machine learning models approved, declined and priced applications in seconds, using bureau data, open finance data shared with consent and in-app behaviour. Growth was strong. Complaints were the warning sign: declined customers could not get a useful answer about why, and when the team reviewed a decision it meant piecing together logs from several services.
Why now. Brazil's data protection law, the LGPD, already gives people the right to request review of decisions taken solely through automated processing that affect their interests, including credit profiling, and to receive clear information about the criteria used1. The national data protection authority, ANPD, oversees it2. On top of that, Brazil's AI bill, PL 2338/2023, passed the Senate in December 2024 and was pending in the Chamber of Deputies, with a vote reported as expected after the October 2026 elections345. It is not law yet, but a lender relying on automated credit decisions could not afford to wait.
What had to be true
- Every decision reconstructable: model version, data used and outcome, stored together.
- Clear reasons a customer can understand, without exposing trade secrets.
- Human review on request, handled quickly with full context.
- Governed models: tested before release and monitored after.
- Data minimised and documented, especially open finance data used with consent.
Architecture
The data flow, end to end
- ApplyApplication submitted with consented data sources
- RulesPolicy rules applied first, with their own reasons
- ScoreVersioned model scores; top factors extracted
- RecordDecision, inputs, versions and reason codes stored together
- ExplainCustomer sees outcome, main reasons and how to ask for review
- ReviewAn analyst reviews with full context and can overturn
The hard part: reconstructing a decision months later
A review request can arrive weeks or months after the decision. By then models have been retrained and data has changed. The team made the decision record immutable and complete at the moment of decision, and linked each application event to the processing that handled it with distributed tracing. OpenTelemetry instrumentation for Kafka links the receive and process steps of a message in one trace, so analysts can follow an application from arrival to outcome6.
An explanation you generate later is a story. An explanation recorded at decision time is evidence. Build for the second.
Reason codes were generated from the model's own attributions and mapped to plain-language statements reviewed by legal and customer teams, so explanations were truthful without revealing model internals. More on evidence and evaluation in evaluation sets that predict production and high-impact AI in hiring.
How it ran
- Policy rules
- Reason code library
- Model approval
- Decision service
- Decision record and tracing
- Monitoring
- LGPD requirements
- Customer wording
- Review process
- One decision service
- Policy rules separated
- Model registry
- Immutable decision records
- Tracing
- Data catalogue
- Reason codes
- Customer messages
- Review workbench
- Release gate
- Drift monitoring
- Overturn analysis
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| One decision service | Scoring spread across services | One place to record, explain and govern |
| Record at decision time | Reconstruct from logs on request | Models and data change; records must not |
| Reason codes from model attributions | Generic decline messages | Truthful, useful and consistent explanations |
| Policy rules before models | Model-only decisions | Hard limits are easy to explain and audit |
| Prepare for the AI bill now | Wait for the final text | The LGPD already requires most of this |
What I'd do again, and differently
Again: consolidate decisions into one service before adding explanations; scattered logic cannot be explained. Differently: track overturned decisions from day one. They were the clearest signal of where models or rules needed work. Related: structured outputs and where I work.
If you make automated decisions about customers in Brazil or elsewhere in Latin America, my AI architecture work explains how I approach it, or analyse your challenge and bring the result to a call.
- 1Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais)Presidência da República (Brazil)
- 2
- 3Brazil's AI bill PL 2338: approved, not lawCASRAI · 2026
- 4Brazil's AI bill misses fourth deadline in a rowEntercast Consulting · 2026
- 5Bill 2338/2023: where Brazil's AI framework stands in 2026Bairo Gonzalez · 2026
- 6Instrumenting Apache Kafka clients with OpenTelemetryOpenTelemetry blog (Paolo Patierno) · 6 Sep 2022