Skip to content

PII: Auto-classification never re-evaluates an already-tagged column, so no improvement can ever take effect #32129

Description

@pmetras

Is your feature request related to a problem? Please describe.

Once auto-classification has applied a tag to a column, that column is skipped on every subsequent run. The first verdict becomes permanent until a human intervenes, even though the tag is applied in state Suggested, which by definition means it has not been validated.

The consequence is that no improvement can ever reach data that has already been scanned:

  • Better recognizers cannot refine an existing classification. Tuning a recognizer, adding context words, correcting a regex does not apply to columns already tagged.
  • Fixes to OpenMetadata's own scoring cannot apply retroactively. See PII: PII content score is divided by the sample size, diluting real findings below any threshold #32070
  • New data cannot change the verdict. A column that was benign when first sampled and has since accumulated sensitive values stays untagged; a column tagged on a false positive stays tagged.
  • False positives cannot be corrected by fixing their cause. Correcting the recognizer that produced a wrong tag does not remove the tag.

In https://github.com/open-metadata/OpenMetadata/blob/main/ingestion/src/metadata/pii/processor.py#L103, as soon as a column carries any tags whose name contains the string "PII", the function returns early. It ignores state so a Suggested tag blocks analysis like a Confirmed one, excluding the column from all future analysis.

That is the wrong way round. A suggestion is precisely the thing that should be revisited as the system improves; a human-confirmed decision is the thing that should be left alone.

Describe the solution you'd like

Re-evaluate on every run, and use the tag state to decide what to preserve:

  • state: Suggested: re-evaluate, and update or remove the tag according to the new result.
  • state: Confirmed / human-applied: leave untouched, as today.

If unconditional re-evaluation is considered too expensive on large databases, an explicit opt-in would still be a large improvement over the current situation. For example a forceReevaluation flag on the auto-classification pipeline config, or re-evaluation triggered when the recognizer configuration of a candidate tag has changed since the tag was applied.

At minimum, skipped columns should be reported. Today a run that skips everything is indistinguishable from a run that analysed everything and found nothing.

Describe alternatives you've considered

No response

Additional context

No response

Pre-submission checklist

  • I searched for duplicate feature requests.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    Status
    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions