[P3][audit][detection] Presidio (Carrion Crow) — 4 learnings acionáveis: decision_process provenance (PRIO) · DICOM gap · salted-hash · batch API contract #1054

Recomendatório (Claude = RO auditor; Cursor implementa/decide). Origem: post-mortem competitivo (Carrion Crow) de 27/jun. Presidio já é considerado em docs/plans/PLAN_ADDITIONAL_DETECTION_TECHNIQUES_AND_FN_REDUCTION.md — esta issue consolida os learnings acionáveis.

Posicionamento (a chave — não é cópia)

Presidio (Microsoft) = library/SDK (público = quem CONSTRÓI pipeline). Data Boar = produto standalone (DPO/CISO instala-usa-apresenta em auditoria; dashboard/Excel/heatmap/evidência). Camadas complementares, não concorrentes. O sidecar Remora PODERIA consumir Presidio como recognizer-engine (opt-in, se o cliente já usa). Colher lessons, não regredir o diferencial.

Learnings acionáveis (4)

1. ⭐ decision_process / provenance (PRIORIDADE) — rastreabilidade de QUAL recognizer/score/contexto gerou cada finding (1ª classe no Presidio). DB já tem norm_tag/pattern_name/sensitivity, mas formalizar como contrato de provenance reforça o moat forense/evidence-grade ("evidence, not legal conclusion"). É o de maior valor dos 4.
2. DICOM redaction = provável GAP — imagens médicas (prontuário/laudo/exame) são vetor de saúde (LGPD Art.5 II + menor Art.14). Verificar se PLAN_IMAGE_SENSITIVE_DATA_DETECTION.pt_BR.md cobre DICOM; se não, é gap a marcar.
3. Salted-hashing (audit) — o sidecar de tokenização/pseudonimização sem-HSM (hash) DEVE usar salt obrigatório (anti-brute-force / anti-rainbow). Auditar que não há hash sem salt.
4. Batch{Analyzer,Anonymizer} — contrato de batch explícito — ajuda o Plugin SDK (epic(sdk): formalizar Boar Plugin SDK — contrato agnóstico versionado + fronteira L1/L2/L3 + fail-graceful (plugin = superfície do sidecar) #865). DB tem max_workers parcial; um contrato de batch formal padroniza o sidecar.

⚖️ Trava do auditor (sem fanboyism)

LangExtract / LLM-recognizer = CUIDADO. É gap real (Presidio admitindo o teto de regex+NER), MAS tensiona o diferencial "zero-LLM, o dado não sai" (moat que brilhou no Futurex). Se um dia entrar: estritamente opt-in sidecar (Remora), LOUD-separado, só contexto anonimizado, NUNCA no core, e marketing que não solape o pitch zero-LLM-core.

O que DB tem e Presidio não (não regredir)

Compliance Art-por-Art · output DPO/CISO (Excel/heatmap/exec-MD) · integridade de artefato (anchor/SIEM) · minor detection cross-ref · quasi-id aggregation · jurisdiction hints · open-core degradação graciosa · BR (CNPJ alfanum, CPF dígito-verificador, PEP, NIS/PIS).

AC sugerido

• Enriquecer docs/plans/PLAN_ADDITIONAL_DETECTION_TECHNIQUES_AND_FN_REDUCTION.md (provenance + posicionamento Presidio-as-sidecar) + python scripts/plans_hub_sync.py --write + entry em PLANS_TODO.md
• decision_process/provenance: spec do contrato (recognizer/pattern/score/contexto por finding) — prioridade
• DICOM: verificar PLAN_IMAGE_SENSITIVE_DATA_DETECTION.pt_BR.md; se gap, adicionar vetor de imagem médica
• Salted-hashing: auditar o sidecar de tokenização (salt obrigatório)
• Batch API contract: conectar ao Plugin SDK (epic(sdk): formalizar Boar Plugin SDK — contrato agnóstico versionado + fronteira L1/L2/L3 + fail-graceful (plugin = superfície do sidecar) #865)
• LangExtract/LLM: documentar como NÃO-core, opt-in sidecar LOUD (preservar moat zero-LLM)

Relacionado: #865 (Plugin SDK), #884 (sidecar sample), PLAN_ADDITIONAL_DETECTION_TECHNIQUES_AND_FN_REDUCTION.md, PLAN_IMAGE_SENSITIVE_DATA_DETECTION.pt_BR.md.