Your client's AI LQA report is creating unpaid work. Here is how to scope it.

The report arrives in seconds. Reviewing it becomes another job.

The translation is delivered. Then the client sends an AI-generated quality report and asks your linguist to implement the feedback. There are hundreds of entries, long explanations and proposed severity labels. Some findings are valid. Others need context, repeat another flag or describe an acceptable choice. Your team still has to read them.

If the quote covered a final correction pass, this additional adjudication can consume the margin on the job. A rejected finding may require more investigation than a straightforward edit. Counting changed words will not show that work.

This is a firsthand concern in an LSP owner's discussion of AI-generated LQA reports. A separate localization discussion about administrative workload describes the time required by reports and scorecards alongside lower post-editing rates. These are practitioner accounts, not a measured industry average.

Start by establishing what the client needs returned. A corrected translation, a decision on each finding and a labeled dataset for evaluating a model are different deliverables. They should not appear accidentally inside the same instruction to check the report.

Separate the work before you estimate it

• Finding adjudication: decide whether the supplied evidence supports the issue under the agreed requirements.
• Translation correction: change the target where a valid finding requires it.
• Dispute resolution: resolve disagreements about meaning, requirements or severity.
• Evaluation feedback: provide structured explanations or labels for a separately agreed system evaluation.

Ask whether a standard reason code is enough for an unsupported flag. A paragraph defending every acceptable translation adds a different level of effort. Reserve free text for cases that need it, and agree the rule with the client before review starts.

Also ask how the feedback will be used. A response can support an evaluation or a prompt change without becoming model training data. Establish the intended use and permissions rather than assuming that every correction automatically trains a model.

Make every decision traceable to the supplied report

Require a stable finding ID, segment ID, report version, source and target text, proposed category and severity, and the cited requirement. Include the relevant glossary or style-guide version. When the evidence is missing, record a blocked decision and request context.

Use a compact outcome set: valid; real issue with corrected category or severity; unsupported; duplicate; outside scope; blocked. Preserve the original AI entry alongside the human conclusion. The reviewer should not have to overwrite the original claim to correct it.

Keep decisions attached to the file version they evaluated. If a client regenerates a report against a revised target, identify which entries genuinely match. A similar sentence or row position is not enough to carry approval forward.

Price from observed effort, including the work around the edits

Run a paid pilot on a mixed sample of categories, severities, explanation lengths and contextual difficulty. Avoid choosing only the first rows or only obvious false alarms. Track setup, reading, decisions, target edits, explanations and client questions separately.

Let reviewers correct timing records and exclude interruptions. An open page or a timer left running does not establish approved billable effort. The purpose is a usable estimate, not a ranking of linguists by clicks.

Use a range when reports vary. An hourly pilot with an agreed cap may fit uncertain input. A fixed fee becomes more defensible when report format, finding mix and required explanations are stable. Define how duplicates, blocked cases and regenerated reports affect that fee.

Include an approval checkpoint when the report differs materially from the sample. If the client wants a different output or supplies a new version, the PM should be able to pause and agree the change before the linguist absorbs it.

Deliver a useful decision record, not another unexplained score

The MQM Council's scoring guidance ties evaluation to project specifications, error types, severities and scoring parameters. Agree those inputs before a quality score becomes a commercial dispute. Preserve the configuration used for the evaluation.

Report valid findings, unsupported flags, duplicate entries and blocked cases separately. Define which outcomes enter any precision calculation. Do not turn the rejected-flag share into a claim about all errors in the translation.

Recall requires evidence about missed issues too. Inspect content outside the flagged list and have qualified reviewers establish the actual errors. A tool that reports nothing can look quiet while missing important defects. Compare quality and effort together.

For ways to improve the automated findings themselves, read AI translation quality assurance: fewer false flags. This article addresses the commercial and operational work that remains after a report arrives.

Start with one report and an acceptance checklist

A spreadsheet may handle the pilot. Build a dedicated intake or review interface only when repeated imports, version conflicts or missing decision history cause measurable rework. Require a new interface to preserve the same decisions and export a usable result.

For a focused discovery call, bring an anonymized report format and the output your client requires. We can discuss where the handling work occurs and whether configuration, a small integration or a dedicated review step is justified. The first decision is what to improve and how you will measure it.