The case: one scratch, four data sources

TUBEIQ, a Serbian SME that builds low-code process-automation systems, worked with DunavNET and rental operator AAA-1 RENT to develop Damage Control. The platform prepares vehicle-damage reports from photographs, voice descriptions, documents and inspection history.

The problem looks modest until every manual step is counted. An employee has to photograph the vehicle, listen to a comment, compare earlier records, identify the damage type and location, and produce a consistent report for the rental company or insurer. When every source lives in a separate system, one small scratch can quickly acquire a three-volume biography.

The project combines computer vision, speech recognition, OCR and generative AI in one workflow. Its output is a structured, machine-readable report that can be passed to rental, fleet-management or claims systems.

What the project confirms

FFplus reports that the team used the LUMI supercomputer to train, fine-tune and compare open models in parallel. The experiments consumed 6,162 GPU node-hours. Parallel testing reduced development cycles from weeks to days and helped the team identify a more accurate approach.

AAA-1 RENT contributed domain expertise, business requirements and validation in a real workflow. Project materials describe high accuracy in detecting and explaining damage, but they do not publish a numeric metric, test-set composition or error thresholds. The defensible conclusion is that the workflow was validated; the same quality must still be demonstrated on another fleet.

The benefits page lists 30–40% faster report processing, 20–25% lower inspection and reporting costs, and up to 30% fewer disputes as projected outcomes. The planned market launch within three to six months and more than €500,000 in three-year revenue are forecasts, not financial results already achieved.

Why the workflow matters more than one “smart model”

A similar project does not need one model that sees dents, understands speech, reads forms and knows company rules. A controlled chain of specialised stages is more reliable:

  • the capture app records mandatory camera angles, vehicle ID, time, operator and shooting conditions;
  • a vision component finds candidate regions and compares them with the previous inspection;
  • speech recognition turns an inspector's comment into text;
  • OCR extracts fields from an inspection form, invoice or insurance document;
  • a rules layer checks required fields, allowed values and contradictions;
  • a generative model drafts an explanation and report without replacing the original evidence;
  • a human approves critical conclusions before an integration service sends the result to the system of record.

The primary artefact should be a JSON object, not an elegant paragraph. It should contain photo identifiers, defect coordinates, model version, confidence, extracted fields and the reviewer's decision. A human-readable report can be generated from that record. If a dispute occurs, the company can reconstruct why the system called a mark a new bumper scratch rather than a particularly theatrical shadow.

Data requirements

A minimum pilot dataset includes before-and-after photo pairs, labels for damage type, location and severity, voice-note samples, document forms and the final decision from an experienced inspector. Data must be split by vehicle, not by random image. Putting photographs of the same car in both training and test sets will produce an unrealistically favourable score.

Hard cases need explicit coverage: dirt, rain, glare, night-time capture, different phones, existing damage, replaced parts, poor audio and missing views. A separate test set should remain fixed between model versions.

Vehicle images, voices, document numbers and customer information may contain personal or commercially sensitive data. A Russian deployment needs its own legal and security review covering data minimisation, retention, access control, export logging and scheduled deletion. Local deployment is useful, but it does not turn an ungoverned photo folder into a secure system by itself.

Infrastructure: the supercomputer is not a permanent requirement

LUMI served as a research accelerator in this case: many model variants were trained and compared in parallel. This does not mean every rental desk needs a supercomputer next to the car wash. After models are selected, a production architecture can separate the workload:

  • lightweight image-quality checks run on a workstation or mobile device;
  • vision, OCR and speech processing run on one GPU server or in a private cloud;
  • a suitably sized local language model produces the report;
  • originals and versioned outputs are kept in object storage with immutable identifiers;
  • a queue and API connect stages so that one component failure does not lose the inspection.

The case materials do not disclose production memory or throughput requirements. They cannot be inferred from 6,162 GPU node-hours, which describe development compute rather than a production-server specification. Hardware procurement requires a separate benchmark using the company's own images, latency target and daily inspection peak.

Pilot economics: count minutes before promises

The following is a model, not a TUBEIQ result. Suppose a company performs 1,000 inspections per month. A manual report takes 15 minutes; after implementation, an employee spends seven minutes reviewing and correcting the draft. The saving is about 133 hours per month.

At a fully loaded labour cost of RUB 900 per hour, that is roughly RUB 120,000 in gross monthly benefit. If the server, storage, support and quality control cost RUB 70,000 per month, about RUB 50,000 remains. A RUB 600,000 integration would break even in around a year under these assumptions. If frequent errors raise review time to 12 minutes, most of the benefit disappears: the robot is still busy, but finance has stopped applauding.

The unit metric is not images recognised but cost per accepted report:

  • share of inspections completed without a repeat photo session;
  • median time to approval;
  • manual correction rate by field;
  • missed new damage and false alerts;
  • number of disputes and time to resolve them;
  • infrastructure and support cost per approved report.

A small first step

A pilot can cover one pickup location, one vehicle class and 200–500 inspections in shadow mode. The system drafts the report, while the employee continues to make the decision through the existing process. After four weeks, the team compares speed, errors and disagreements.

Before launch, define acceptable thresholds for missed damage and false alarms, mandatory photo angles, recapture rules and actions that AI cannot perform autonomously. Only damage types that remain stable on the company's own data should move into production.

Management takeaway

Multimodal AI creates value through evidence linkage, rules, integration and human approval, not through one more model. Start with one measurable step—drafting the report—and do not automate disputed-case decisions until the metrics survive real lighting, dirt and Monday morning.