AI for field inspections (CEDAE)

CEDAE, Rio de Janeiro's state water and sewage utility, ran the registration and re-registration of customers across an entire region of the state's interior: over 10,000 residential, commercial and industrial inspections, carried out by field teams in several municipalities at once. Each inspection's data reached the administrators, who ran the rest of the operation and reported to the utility.

Vibetex's platform covered the whole cycle: a field app with forms, geotagged and timestamped photos, document capture with OCR and e-signatures, real-time team tracking and performance reports. It was already in production when I joined. A Vibetex colleague and I built the AI layer, the part that analyzed the data generated by the inspections, from April to September 2026, when the contract ended. It was our first AI project in production, with real, confidential data from a public client.

Automatic classification: every incoming inspection was classified into the categories the operation used, without someone reading record by record.

Summaries: each inspection got a summary for the administrators and for CEDAE, who needed to understand a site without opening the full record.

Inconsistencies and metrics: as each inspection arrived, the AI cross-checked it against the registry and flagged problems such as a duplicated address or a neighborhood that didn't match the site, while feeding operational metrics, so administrators could act before a problem spread.

Natural-language chat: users asked questions in Portuguese and the assistant looked up the answer in the operation's real data, such as who owned a property, which technician inspected it, whether an address was duplicated or a neighborhood wrong, and the payment status. All from an assistant acting on behalf of Vibetex in service to CEDAE.

The hardest decision was not to give the AI power over the data. It was real data from the client, with a lot of confidential information. We duplicated the database in a CQRS-like setup: production sends the information to a separate, read-only database, and that's the only one the AI can reach. The chat turns the question into a read-only SQL query; editing or deleting isn't possible, by permission, not by an instruction in the prompt.

For the repetitive functions, which refreshed many times a day (a property's owner, the technician who inspected it, duplicated addresses, payment status, operational metrics), I used the tools mechanism (function calling) and ended up building many of them. Instead of building the query from scratch for each question, the model called a ready-made function with the right parameters, and some tools carried their own query. Free-form queries were left only for questions outside the usual patterns.

Every model output came as structured JSON and was validated before use. The per-inspection analyses ran as soon as an inspection arrived; the chat ran per interaction, on each question.

Sensitive data never appeared in full: following Brazil's LGPD, it was masked with asterisks, leaving only part of the characters visible. On top of that came prompt injection protection and a well-defined role for the assistant, so it wouldn't stray from serving CEDAE.

Controlling cost in an environment that was already large and in production. Every decision about how much context to send the model showed up on the bill, and we learned that by measuring, not by reading.

The model made plenty of mistakes and hallucinated under the volume of information. There was a lot of agent training, but done by hand: in April I didn't yet know techniques like fine-tuning, so almost all the knowledge went into the agent's internal prompt, which grew very large. An even bigger share of the time went into fighting cross-query contamination and prompt injection attempts. That's where I understood the difference between using a model and doing AI engineering.

The project closed with over 10,000 inspections going through the AI layer and with a technical capability certificate issued by CEDAE to Vibetex, which records the contract's execution as fully satisfactory, including the artificial intelligence dedicated to analyzing the inspection data. It's the most important work of my career so far.

Today I'd go beyond sending data to a model. A more structured RAG, with embeddings and semantic search, so the model only receives what matters and hallucinates less. An architecture with several agents, each with one job (classify, summarize, query, audit), connected through MCP. And, with the dataset the project accumulated, fine-tuning for the repetitive tasks.

On security, I'd obfuscate the data more professionally, strengthen the guardrails following the OWASP Top 10 for LLMs and reinforce protections in both the code and the prompt. And I'd build an admin audit screen with cost and tokens per feature. With all of that measured and tied together, the AI could be given more permissions safely. Several of these ideas are already in Nox, this site's chat.