By · Last updated 2026-03-13

Volver al BlogSeguridad de IA

Cómo Samsung Perdió Código Fuente Propietario a...

Tres equipos de ingeniería de Samsung pegaron código propietario y datos confidenciales en ChatGPT en abril de 2023.

March 13, 20269 min de lectura
Samsung ChatGPT leaksource code protectionenterprise AI controlsinsider data leakageMCP Server anonymization

Actualizado para 2026

Tres equipos, tres filtraciones, un mes

En abril de 2023, Samsung Semiconductor divulgó tres incidentes separados. Tres equipos diferentes habían enviado datos propietarios a un chatbot de IA en el transcurso de un solo mes. Los incidentes no estaban relacionados. Personas diferentes, roles diferentes, días diferentes.

Solo compartían dos características. Cada persona usó la herramienta para trabajo real. Cada una envió accidentalmente datos que Samsung no pretendía compartir fuera de la empresa.

Incidente 1 — Código fuente. Un ingeniero de software estaba depurando código de equipos. Pegó código fuente propietario de semiconductores en el chat. El código contenía propiedad intelectual de fabricación.

Incidente 2 — Notas de reunión. Un empleado preparaba un resumen de una reunión. Envió sus notas para que la IA las condensara. Esas notas contenían información estratégica confidencial y detalles de hoja de ruta.

Incidente 3 — Consulta de base de datos. Un tercer empleado quería ayuda con una consulta lenta. Compartió la estructura de la base de datos y la lógica de consulta. Esa lógica referenciaba esquemas propietarios y reglas de negocio.

Tres incidentes. Tres divulgaciones. Un mes.

Por qué lo hicieron los empleados

Ninguno de los tres actuó de forma descuidada. Usaron una herramienta de IA para tareas para las que las herramientas de IA están diseñadas. Revisión de código. Síntesis de texto. Optimización de consultas. Cada tarea era legítima.

El elemento que faltaba era una barrera técnica. Ningún sistema bloqueó el envío antes de que llegara a un servidor externo. Ningún filtro detectó los identificadores propietarios antes de que abandonaran la red. Nada se interponía entre la necesidad real del empleado y el servicio externo.

Existía una advertencia de política. Pero una advertencia no es una barrera. El riesgo de un error accidental era abstracto y lejano. El beneficio en productividad era real e inmediato. Los trabajadores racionales eligieron la productividad.

El resultado era predecible. Tres incidentes en treinta días. Tres divulgaciones de propiedad intelectual. Una crisis corporativa que desencadenó prohibiciones en toda la industria.

La reacción de la industria

Samsung actuó rápidamente. Restringió el acceso a herramientas de IA en los dispositivos corporativos.

Otras organizaciones siguieron su ejemplo. Entre las que anunciaron restricciones se encontraban Bank of America, Citigroup, Goldman Sachs, JPMorgan Chase, Apple y Verizon. El sector financiero reaccionó más rápido. Los grandes bancos y empresas tecnológicas llegaron a la misma conclusión. Las herramientas de IA sin controles técnicos representaban un riesgo de cumplimiento inaceptable.

Todas ellas llegaron al mismo hallazgo. Los empleados no son el problema. Las advertencias de política no son suficientes. Los datos abandonaban las redes corporativas porque nada los detenía. La política por sí sola no puede crear una barrera técnica.

La tasa de evasión del 71,6 %

El enfoque de prohibición tiene una tasa de fracaso medida. Una investigación de LayerX de 2025 encontró que el 71,6 % de los empleados sujetos a prohibiciones de IA empresarial continuaron usando herramientas de IA. Usaron cuentas personales o dispositivos personales.

La razón es simple. Una herramienta que aporta valor real se usa. Las personas encuentran soluciones alternativas antes que renunciar a ella. La IA puede reducir a la mitad el tiempo de las tareas. Una advertencia de política no cambiará ese cálculo. Los trabajadores inician sesión desde un teléfono o portátil personal. Los equipos de seguridad no pueden ver ese tráfico.

El resultado práctico es el peor caso. Los datos corporativos siguen llegando a los proveedores de IA. Pero ahora fluyen a través de canales sin ninguna supervisión. El tráfico de dispositivos corporativos al menos podría registrarse. El uso de cuentas personales es invisible.

Los tres incidentes de Samsung ocurrieron en dispositivos corporativos. Los empleados que evaden la prohibición hacen lo mismo. Envían datos de trabajo a modelos de IA. Pero ahora lo hacen a través de canales sin visibilidad empresarial.

La solución técnica para la causa raíz

Los incidentes de Samsung no fueron causados por personas descuidadas. Fueron causados por una arquitectura sin capa de interceptación. No había nada entre el prompt del empleado y el servidor del proveedor.

La arquitectura Model Context Protocol (MCP) llena ese vacío. Coloca un proxy transparente en el camino de los datos. Los desarrolladores que usan Claude Desktop o Cursor IDE son la audiencia principal. Esas son exactamente las herramientas utilizadas para el tipo de depuración de código detrás del primer incidente de Samsung. El servidor MCP se encuentra dentro del camino del protocolo para ambas.

Antes de que cualquier texto llegue al modelo de IA, el servidor MCP lo hace pasar por un paso de anonimización. El código fuente se analiza en busca de identificadores propietarios. Los nombres de funciones, nombres de variables y endpoints de API se reemplazan con tokens estructurados. Los detalles del esquema de base de datos y los valores de configuración también se reemplazan. El intercambio ocurre antes de que el código abandone su red.

Un desarrollador que depura código propietario envía el código a través del cliente MCP. Los identificadores sensibles ya son tokens en ese momento. El modelo de IA sigue ayudando con la tarea de depuración. Los detalles propietarios reales nunca llegan a los servidores del proveedor.

El incidente 1 se vuelve técnicamente imposible. El código fuente sale de la red ya anonimizado. El ingeniero recibe la ayuda que necesitaba. La propiedad intelectual permanece bajo control de la empresa.

La misma lógica aplica al incidente 2. La síntesis de notas de reunión mediante herramientas basadas en navegador está cubierta por la extensión de Chrome y sus controles empresariales. El incidente 3 está cubierto por la anonimización MCP en cualquier interfaz de codificación de IA.

Prohibiciones vs. controles técnicos

Prohibir herramientas que el 71,6 % de los empleados ya evade no reduce el riesgo. Mueve el riesgo a canales invisibles.

La comparación de herramientas DLP de navegador cubre las opciones de interceptación para el uso de IA basado en navegador. Para organizaciones que comparan la anonimización con otros productos DLP, la comparación Nightfall vs. anonym.legal aborda directamente el compromiso entre bloqueo y anonimización.

Los incidentes de Samsung fueron una señal temprana. La causa raíz era una ausencia. Sin capa de interceptación. Sin control técnico. Ese vacío es ahora corregible. La pregunta es si las empresas implementan la solución, o siguen dependiendo de prohibiciones que la mayoría de los empleados ya sortean.

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.