By · Last updated 2026-04-02

Volver al BlogSalud

Por qué los LLMs fallan en el 50% de la PHI clínica...

Un estudio de 2025 encontró que los LLMs fallan en más del 50% de la PHI clínica en documentos multilingües.

April 2, 20269 min de lectura
LLM PHI detectionHIPAA de-identificationclinical NLPSafe Harbor methodhealthcare AI compliance

El problema del 50 % de omisiones

Un estudio de 2025 (arXiv:2509.14464) probó herramientas LLM en registros clínicos. Los resultados fueron malos. Estas herramientas omitieron más del 50 % de las PHI clínicas en documentos multilingües. La causa es simple. Los LLM están diseñados para generar texto. No están diseñados para la detección de alta cobertura que exige HIPAA.

HIPAA Safe Harbor lista 18 tipos de identificadores protegidos. Nombres, fechas, números de teléfono, SSN, MRN, identificadores de planes de salud, identificadores de dispositivos y direcciones IP. Cada uno requiere su propia lógica de detección.

Las notas clínicas lo hacen más difícil. Tomemos este ejemplo: "Pt. John D., DOB 4/12/67, MRN 1234567, ingresado el 03/15/24, Dr. Smith ordenó ECG." Una sola oración. Cinco identificadores protegidos. La mayoría usa formas abreviadas. Un modelo diseñado para el significado clínico suele fallar en la tarea de detección.

Lo que los LLM omiten y por qué

Las herramientas LLM fallan en los registros clínicos de maneras predecibles.

Identificadores abreviados: Las notas clínicas usan taquigrafía. DOB, MRN y Pt. son formas comunes. Un modelo orientado al significado clínico puede no marcar "Pt. John D." como nombre. La extracción de datos sensibles necesita un objetivo diferente.

Fechas dependientes del contexto: No todas las fechas representan el mismo riesgo. "Edad 67" es un marcador indirecto. "DOB 4/12/67" es un identificador protegido directo. "03/15/24" como fecha de ingreso también está protegida. La coincidencia de patrones sola no es suficiente.

Formatos no estadounidenses: Cyberhaven (T4 2025) encontró que el 34,8 % de todas las entradas de ChatGPT contienen datos sensibles, incluidos PII multilingües. En salud, esto incluye identificadores de registros no estadounidenses, formatos de fechas regionales y tipos de ID de salud locales. Las herramientas entrenadas en EE. UU. los omiten sistemáticamente.

Identificadores hospitalarios personalizados: Los hospitales usan sus propios formatos de MRN, identificadores de personal y códigos de sitio. Estos no aparecen en los conjuntos de entrenamiento NER estándar. Una herramienta sin soporte de entidades personalizadas no los encontrará.

El riesgo en conjuntos de datos de investigación

Un hospital que construye un conjunto de datos de investigación con 500.000 notas enfrenta un problema real de cumplimiento. HIPAA exige un estándar de "muy bajo riesgo" para los datos anonimizados. Una herramienta que omite la mitad de todos los identificadores protegidos no puede cumplir ese estándar.

Los archivos de investigación no son datos limpios. Las notas abarcan muchos departamentos, períodos de tiempo y a veces idiomas. Una herramienta que funciona en datos de facturación puede fallar en notas narrativas. Los datos sensibles en texto libre no tienen etiqueta de campo.

La aprobación del IRB añade más exigencias. Las instituciones deben mostrar el método usado, los tipos de identificadores eliminados y las verificaciones realizadas. Una herramienta que omite la mitad de todos los registros no puede cumplir esas exigencias.

Consulte nuestro resumen de cumplimiento y prácticas de seguridad para saber cómo anonym.legal apoya los flujos de trabajo HIPAA.

La solución de tres capas

El estudio de 2025 encontró un patrón claro. Las herramientas con las tasas de omisión más bajas usaron tres capas de detección.

Capa uno — regex: Encuentra identificadores estructurados. SSN, MRN, números de teléfono, identificadores de planes de salud. Confiable en formatos fijos.

Capa dos — NER: Usa modelos transformadores. Encuentra nombres, fechas y datos sensibles en texto narrativo. Funciona donde el regex no puede.

Capa tres — entidades personalizadas: Maneja formas específicas del sitio. Patrones MRN propietarios, identificadores de personal, códigos de instalación. Ningún modelo estándar cubre estos.

Las herramientas de ML puro se degradan con formas abreviadas y texto no inglés. Las herramientas de regex puro omiten datos sensibles sin etiqueta de campo. Ninguna por sí sola es suficiente.

Solo el diseño de tres capas alcanzó tasas de omisión por debajo del 5 % en el estudio. Ese es el umbral para el cumplimiento de HIPAA Safe Harbor.

Consulte nuestra guía sobre anonimización HIPAA Safe Harbor para investigación para los próximos pasos.

Fuentes

¿Listo para proteger sus datos?

Comience a anonimizar PII con más de 285 tipos de entidades en 48 idiomas.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.