On September 23, 2026, a report by O Globo stated that some chambers of Brazil's Supreme Federal Court (STF) had assigned teams, albeit small ones, to analyze the contents of a seized cell phone: about 510 GB across 32.7 thousand files, including chats, audio recordings, and call logs. The challenge, according to sources heard by the newspaper, is the lack of people to read and listen to everything without bringing the rest of the work to a halt.
A team of 4 part-time people would take 3 to 9 months (about 5, under the assumptions of this exercise) to read the messages and listen to the audio. An architecture on Databricks, with the models running in Brazil, cuts that down to days of automated processing and a few weeks of human review, with an estimated processing cost of US$675 to 875, plus about US$5 thousand per month to keep the platform running during the review.
How long would manual reading take?
Let's stop and estimate how long a team of roughly 4 people, working part-time, would take to analyze this dataset. Suppose the volume in the report corresponds to about 500 thousand messages and 500 hours of audio, with documents and images making up the rest of the 510 GB.
Taking a few assumptions into account:
- Team capacity: 4 people times 4 h/day = 16 h/day, with about 21.75 working days per month.
- Reading about 500 messages per hour, attentively and with some notes.
- Each hour of audio takes about 1.5 hours of analysis, counting pauses, replayed passages, and notes.
- The estimate covers messages and audio. Images and documents, which account for most of the 510 GB in bytes, are left out, which makes the estimate conservative.
With these assumptions, that comes to about 1,750 hours of work, or about 5 months (the team adds up to 348 h per month). The timeline changes a lot with the reading pace. In a screening read, with 1,000 messages per hour and each hour of audio taking 1.2 hours of analysis, it would be about 1,100 hours, or 3 months. In a careful analysis, reading 250 messages per hour, with each hour of audio taking 2 hours of analysis, it would be about 3,000 hours, or about 9 months.
Anyone who works with data architecture knows that analyzing 510 GB of information is not really such a complex case. The complexity lies in the legal context, where confidentiality and control over the data are critical, and in the time savings an automated solution can bring.
This article treats the report as a source of requirements for a data architecture problem and proposes an architecture on Databricks for this type of analysis. The goal is not to give an opinion on the case or on the contents of the device. It is to show how ingestion, transcription, LLMs, and governance can turn months of reading into days of automated processing, followed by human review of whatever is flagged, and to discuss the solution's limits from a technical, legal, and ethical standpoint.
Requirements extracted from the report
First of all, we need to understand what actually needs to be done and list the solution's requirements, functional and non-functional.
| ID | Requirement | Evidence in the report |
|---|---|---|
| RF01 | Ingest about 510 GB and 32.7 thousand heterogeneous files | Chats, audio recordings, and call logs |
| RF02 | Transcribe audio in Portuguese, with speaker and time | Audio among the files |
| RF03 | Find mentions of people and authorities in the dialogues | Teams look for "the references in the dialogues" |
| RF04 | Restrict the analysis to the authorized scope | Caution to use the material only for what was requested |
| RF05 | Check an existing report against the messages that support or contradict it | The news report mentions the analysis of an official report on the messages |
| RF06 | Generate reports that cite dialogues with a verifiable reference | Forensic reports citing dialogues, mentioned in the news report |
| RF07 | Build a timeline and a contact network | Call logs and conversations with various contacts |
| RNF01 | Restricted access, based on least privilege | The first measure was "to restrict access to the material" |
| RNF02 | Intimate content hidden by default | Large volume of personal and intimate information |
| RNF03 | Isolation between chambers | Five chambers, each with its own method |
| RNF04 | Productivity with small teams | "Lack of hands" on the teams, according to sources quoted in the report |
| RNF05 | Full auditing and traceability | The material is judicial evidence |
| RNF06 | Scale to volumes of several TB | A previous case cited in the report had about 7 TB |
| RNF07 | Processing within the country | Requirement assumed by the exercise: confidential material; follows from RNF01 and RNF05 |
Proposed architecture on Databricks
Based on the requirements, we built a reference architecture that uses the concepts of the medallion architecture (layers that refine the data at each stage) and the lakehouse.
In short, the architecture organizes the material into four layers, within a single perimeter governed by Unity Catalog. In bronze, the files extracted from the device are copied unchanged, each with its SHA-256 hash. In silver, audio is transcribed, chats and calls become normalized tables with a hash per message, documents go through OCR, and possible intimate content is flagged and hidden by default. In gold, an open model served in Brazil extracts people, events, amounts, and dates, always with the literal excerpt and the reference of the source message, and builds the contact graph and the timeline. In consumption, the analyst searches, verifies, and confirms each finding before it goes into a report.
One decision runs through every layer: no model processes the content outside the country (RNF07). On Azure Databricks in São Paulo, the Foundation Model APIs and built-in functions such as ai_classify and ai_parse_document only work with cross-geography processing enabled. That is why every model in this architecture that reads the content of the messages, for transcription, OCR, embeddings, and language, is an open model served on dedicated GPU Model Serving endpoints available in the region.
Bronze layer: ingestion with traceability
The starting point is the data extraction already performed on the device. Auto Loader copies the files to a Unity Catalog Volume and computes the SHA-256 of each one (a fingerprint of the file, which proves it has not been altered). The bronze table is never deleted or compacted, and the Delta history becomes part of the information's audit trail.
Silver layer: structuring
The processes run in parallel:
- Audio goes through Whisper large-v3 on a GPU Model Serving endpoint. In voice messages, the speaker already comes in the metadata (the sender). Diarization, which separates different voices within the same recording, is used for recordings with more than one person; it tells the voices apart, but does not say who each one is.
- Chats and call logs become normalized tables of messages, calls, and contacts, with an explicit time zone. Since the messages all sit inside a single app database, the file hash is not enough: each message gets its own hash, computed over the content and the metadata, and keeps the hash of its source file. That way, any citation can be traced back to the extracted file.
- Intimate content is flagged by a classifier, the same in-house LLM called via ai_query, and those flags become governed tags that hide the content by default.
- Images and documents go through an open OCR model served on GPU, and the extracted text joins the same flow as the messages.
Gold layer: enrichment and correlation
With ai_query over the open model served on the dedicated endpoint, each conversation window produces structured records: people mentioned, events, amounts, and dates, always with the literal excerpt and the hash of the source message. The texts also become embeddings (numerical representations of the meaning of the text), generated by an in-house multilingual model and indexed in AI Search, for search by meaning and not just by keyword. The correlation layer builds the contact graph (who talks to whom, when, and through which channel) and a timeline that can be cross-checked against dates of public events related to the authorized scope.
Consumption layer: human review
This is where the architecture addresses the "lack of hands" (RNF04): the team stops reading everything in sequence and starts reviewing what was flagged, in order of relevance. A Databricks App provides search, filters, and the report verification flow:
- The analyst pastes a paragraph from a report, and the system retrieves candidate messages.
- The LLM sorts these messages into "supports", "contradicts", and "inconclusive", each with a link to the source.
- The analyst confirms or discards each one.
For structured questions about the graph and the timeline, an AI/BI Genie space accepts natural language queries, under the same Unity Catalog rules. Since Genie uses Azure AI Services models, and not the in-house models, it is restricted to the metadata tables (who, when, through which channel), with no access to the text of the messages.
Only what the analyst confirms goes into the reports, which cite the hash of each message and that of its source file.
What if the case is bigger?
For volumes like the 7 TB cited in the report (RNF06), the design does not change. Auto Loader processes the files incrementally, the endpoints gain replicas, and the cost grows with the content to process (hours of audio, messages, and pages), not with the bytes.
Governance and security
Governance in Unity Catalog
Each process gets its own catalog and each chamber, a group with isolated working tables (RNF01, RNF03). Row filters limit each query to the authorized scope (RF04), and tag-based masks hide content flagged as intimate until someone with permission releases it, with a recorded justification (RNF02).
Models inside the perimeter and inside the country
On Azure Databricks in São Paulo, the Foundation Model APIs (pay-per-token and provisioned throughput) and built-in functions such as ai_classify, ai_extract, and ai_parse_document only work with cross-geography processing enabled: the data remains stored in Brazil, but is processed in another region. For confidential material, that will not do.
The alternative is to serve open models on dedicated GPU Model Serving endpoints available in the region and call them via ai_query. The endpoints sit behind Unity Gateway, which controls who can call them, enforces usage limits, and logs every call. Endpoints for external providers stay blocked.
Logs are sensitive data too
Inference tables store prompts and responses, that is, excerpts of the conversations. They need to live in the same governed catalog, with the same access and retention rules.
Network and encryption
Private Link with no exit to the public internet, serverless egress control (data leaving the network), customer-managed keys, and the compliance security profile. The latter requires the Enhanced Security and Compliance add-on, which has its own cost and is included in the numbers below.
How much it costs to run the analysis
Processing the case costs about US$475 per full run and US$675 to 875 in total processing, with every model running in Brazil. Keeping the platform running for the review costs about US$5 thousand per month (R$27.5 thousand).
Assumptions
- Prices: Azure Databricks list prices in the Brazil South region, Premium plan, checked on October 11, 2026 through the public Microsoft pricing API: US$0.112 per DBU for Model Serving, US$0.59 per DBU for serverless jobs, US$1.09 per DBU for serverless SQL and Apps, and US$0.10 per DBU for the Enhanced Security and Compliance add-on. DBU is the Databricks unit of consumption.
- GPUs: a T4 consumes 10.48 DBU/h and an 80 GB A100, 78.6 DBU/h, the equivalent of 1/8 of the 628 DBU/h of the eight-A100 configuration.
- Assumed speeds: Whisper at about 6 times real time on a T4, diarization included; LLM at about 2 thousand tokens per second on an A100, with batch processing.
- Text volume: 500 thousand messages of ~25 tokens and 500 h of audio at ~11 thousand tokens per hour make a corpus of ~18 million tokens. Extraction reads this corpus with a 2.5x overhead (instructions and window overlap), and intimate content classification makes another pass: ~75 million input tokens and ~8 million output tokens.
- OCR: assumption of ~20 thousand pages and images.
- Endpoints shut down at the end of each batch. Exchange rate of US$1 = R$5.50.
One full run
| Stage | Resource | Usage | DBU | Cost (US$) |
|---|---|---|---|---|
| Transcription and diarization of 500 h | Whisper large-v3, T4 GPU | ~85 GPU hours | ~890 | ~100 |
| Intimate content classification and extraction | Open model (e.g., gpt-oss-120b), 80 GB A100 GPU | ~12 GPU hours for ~83 million tokens | ~945 | ~105 |
| OCR of images and documents | Open OCR model, T4 GPU | ~5 GPU hours | ~50 | ~6 |
| Embeddings | Open multilingual model, T4 GPU | ~3 GPU hours for ~25 million tokens | ~30 | ~4 |
| Ingestion and normalization | Serverless jobs | No GPU | ~100 | ~60 |
| Compute subtotal | ~2,020 | ~275 | ||
| Enhanced Security and Compliance add-on | US$0.10 per DBU | ~200 | ||
| Full run | ~475 |
In practice, transcription, OCR, and ingestion run once. What repeats is the LLM extraction, due to prompt adjustments, at about US$200 per pass including the add-on. With one or two extra passes, processing comes to US$675 to 875, or R$3.7 thousand to R$4.8 thousand.
Added up, the GPU stages in Table 2 use about 105 machine hours, or 4 to 5 calendar days with one endpoint per stage, and less with replicas.
What is left for people
Processing does not eliminate human reading; it changes what gets read. If screening reduces the review to 10% to 20% of the material, an assumption that depends on the authorized scope, that would be 175 to 350 hours, calculated over the 1,750 hours of the base scenario: 2 weeks to 1 month for the same team, against about 5 months reading everything.
Monthly operation
| Item | Sizing | US$ per month |
|---|---|---|
| LLM endpoint for the review | 1 A100, ~8 h per working day | ~1,550 |
| Serverless SQL warehouse X-Small | ~120 h per month | ~785 |
| Databricks App | Medium, on 24 h | ~400 |
| AI Search | 1 Standard unit, 24 h | ~325 |
| Storage and private network | ~1.5 TB, Private Endpoints | ~150 |
| Enhanced Security and Compliance add-on | US$0.10 per DBU | ~1,785 |
| Total | ~5,000 |
Serving the models on dedicated GPUs comes at a price: you pay for the machine hours the endpoint is on, not per token. The monthly bill comes to about US$5 thousand (R$27.5 thousand), and the query endpoint plus the security add-on account for two thirds of it. Turning the endpoint off outside working hours and sizing the GPU to actual use are essential to make the solution viable.
Limits and precautions: what AI does not do
The architecture solves the volume problem, but it does not, on its own, solve what makes this case delicate. Some limits are beyond the reach of any platform; others depend on how it is configured.
Technical limits
- The LLM can be confidently wrong. That is why the gold layer requires the literal excerpt and the message hash in every record. An automatic step checks whether the excerpt exists in the source, and whatever does not match is discarded. Even so, extraction is screening, not a conclusion.
- Cell phone audio is hard. Noise, slang, and overlapping speech raise the transcription error rate, and errors tend to fall precisely on proper names, which are the object of RF03. Relevant passages need to be heard by a person before going into a report.
- Who is who. Nicknames, forms of address such as "Doctor", and unnamed contacts require human validation. Diarization separates voices, but does not identify them. A mistake here contaminates the entire contact graph.
- Open models take more work. Serving your own models ensures the content stays in the country, but it requires choosing, testing, and maintaining each model, and measuring its quality in Portuguese before trusting it.
Legal limits
- Confidentiality and data in Brazil. Running the models in Brazil settles where the content is processed, but the data still sits in a foreign provider's cloud. For material under judicial secrecy, that is a legal decision, not a technical one.
- The LGPD does not settle it alone. Brazil's data protection law excludes from its scope data processing carried out exclusively for the investigation and prosecution of criminal offenses (art. 4, III, d). Procedural secrecy and the constitutional protection of privacy apply.
- Purpose. A tool that finds everything makes it easier to search beyond what was authorized. The scope of RF04 needs to be in the access control, in the Unity Catalog filters, and in the Unity Gateway policies, and every question asked of the system should be logged.
- Rules for AI in the Judiciary. CNJ Resolution 615/2025 requires human oversight proportional to the risk and keeps the interpretation of evidence as a human activity. In our reading, if the correlation is used to evaluate people, the system is likely to be classified as high risk.
Ethical limits
- Correlation is not causation. Cross-checking the timeline against public dates is the most tempting part and the most dangerous. A spike in messages near an event can have many explanations, and the graph shows frequency, not the nature of a relationship.
- Exposed third parties. On devices like this, many people only talked to the owner. The intimacy filter needs to protect them too.
- Automation bias. In small, overloaded teams, the very problem that motivated this exercise, the risk of trusting the summary is higher. That is why human review sits at the end of the flow, and every finding leads back to the source.
Implementation cost
- Cheap execution is not a cheap project. Processing the case costs hundreds of dollars, but building, testing, and validating this governance takes months of a specialized team, a timeline this exercise does not estimate and that depends on the scope. And keeping the platform running has its own cost, as Table 3 shows.
Conclusion
The 510 GB in the case reported by O Globo are not necessarily a big data problem. They are a capacity problem: few people, a lot of sensitive material, and the requirement that every conclusion point to the original message.
With governed ingestion, transcription, open models running in Brazil, and semantic search, reading that would take 3 to 9 months becomes days of processing and a few weeks of reviewing what was flagged, with processing costs in the hundreds of dollars and about US$5 thousand per month to keep the platform running during the review. What technology does not do is decide what can be searched, nor replace the people who read. These limits are part of the project, not a detail of it.
Perhaps the most useful lesson is this: with sensitive data, the best architecture is not the one that finds everything, but the one that finds only what was authorized, without taking the content out of the country, and shows where each answer came from.
Planncode is a Databricks and Microsoft partner and designs data platforms like this one. If your organization needs to analyze a large volume of conversations, documents, or audio without taking the content out of the country, talk to us.
Frequently asked questions
How long would a small team take to analyze 510 GB of conversations?
With 4 part-time people, 3 to 9 months to read the messages and listen to the audio, depending on how rigorous the reading is. Under the assumptions of this exercise, about 5 months.
How much does it cost to process this volume with AI on Databricks?
About US$475 per full run, at Azure Databricks list prices in São Paulo, with the models running in Brazil and the security add-on included. Counting the extra extraction passes, between US$675 and 875 (R$3.7 thousand to R$4.8 thousand). Keeping the platform running during the review costs about US$5 thousand per month (R$27.5 thousand).
How much human review is left?
It depends on the authorized scope. If screening reduces the reading to 10% to 20% of the material, that would be 175 to 350 hours: 2 weeks to 1 month for the same team of 4 part-time people.
Does the data leave Brazil?
The content of the messages is processed in Brazil: every model that reads it is open and served on GPUs within the region, because the built-in Databricks models in São Paulo only work with processing in another region. The data stays in a foreign provider's cloud, which is a legal decision (see the last question).
How does the architecture ensure every finding is verifiable?
Each message has its own hash, linked to the hash of its source file. Each record in the gold layer carries the literal excerpt and that hash, and the reports cite both.
Does AI replace the analysts?
No. Extraction is screening, not a conclusion: only what the analyst confirms goes into the reports.
Can this architecture be used with confidential material?
It depends on a legal decision, not a technical one. Even with the models running in Brazil, Private Link, and customer-managed keys, the data stays in a foreign provider's cloud, and CNJ Resolution 615/2025 requires human oversight and risk classification.
Sources and references
- Gabinetes do STF dedicam equipes para analisar celular de Vorcaro, mas veem volume de conversas como desafio. O Globo, September 23, 2026 (in Portuguese)
- Mattos Filho: the future of AI use by the Judiciary (in Portuguese)
- JusDocs: what changes with CNJ Resolution 615/2025 (in Portuguese)
- Revista Algoritmos e Sociedade (UFMG): Resolution No. 615/2025 (in Portuguese)
- TRT4: minutes of the AI Governance Subcommittee, May 2026 (in Portuguese)
- Microsoft: Azure Databricks features with limited regional availability
- Microsoft: Databricks Designated Services and cross-geography processing
- Microsoft: Model Serving endpoints for custom models and GPU types
- Databricks: GPU Model Serving pricing
- Databricks: Unity Gateway documentation
- Law 13.709/2018 (LGPD), consolidated text on the Planalto website (in Portuguese)
- Microsoft: Azure Retail Prices API, Azure Databricks in the Brazil South region (checked on October 11, 2026)