{"id":1890,"date":"2026-04-10T06:00:00","date_gmt":"2026-04-10T12:00:00","guid":{"rendered":"https:\/\/hacking.onesec.mx\/?p=1890"},"modified":"2026-04-09T22:20:15","modified_gmt":"2026-04-10T04:20:15","slug":"traducir-o-no-traducir-el-dilema-del-idioma-en-ciberseguridad","status":"publish","type":"post","link":"https:\/\/hacking.onesec.mx\/index.php\/2026\/04\/traducir-o-no-traducir-el-dilema-del-idioma-en-ciberseguridad\/","title":{"rendered":"\u00bfTraducir o no traducir? El dilema del idioma en ciberseguridad"},"content":{"rendered":"\n

Imagina que recibes un reporte y lees: “El actor de amenaza utiliz\u00f3 un payload hardcodeado para comprometer el sistema aprovechando una vulnerabilidad explotada in the wild, despu\u00e9s de haber realizando fuzzing sobre el endpoint.”<\/em><\/p>\n\n\n\n

\u00bfLo entendiste todo? Seguramente s\u00ed, si llevas tiempo en el gremio. Pero ahora imagina que ese mismo p\u00e1rrafo llega al director de TI de una empresa mediana, o a un estudiante de primer a\u00f1o, o a un abogado que debe presentar el caso ante un tribunal. La historia cambia completamente.<\/p>\n\n\n\n

El debate sobre si traducir o no los t\u00e9rminos t\u00e9cnicos del ingl\u00e9s al espa\u00f1ol en ciberseguridad no es nuevo, pero sigue siendo relevante. La ciberseguridad naci\u00f3 y creci\u00f3 en ingl\u00e9s, y buena parte de su vocabulario lleg\u00f3 al espa\u00f1ol como pr\u00e9stamo directo, sin pasar por aduanas ling\u00fc\u00edsticas. Hoy exploramos el problema a trav\u00e9s de algunos de los t\u00e9rminos m\u00e1s pol\u00e9micos del sector.<\/p>\n\n\n\n

\"Traducir<\/figure>\n\n\n\n
\n\n\n\n

Por qu\u00e9 existe este debate<\/h2>\n\n\n\n

El espa\u00f1ol no es un idioma pasivo. La Real Academia Espa\u00f1ola (RAE), junto con la Asociaci\u00f3n de Academias de la Lengua Espa\u00f1ola (ASALE), lleva d\u00e9cadas lidiando con la avalancha de anglicismos tecnol\u00f3gicos. La postura oficial distingue entre dos tipos de extranjerismos: los superfluos<\/em> \u2014 aquellos que tienen equivalente en espa\u00f1ol y no necesitan ser importados \u2014 y los necesarios<\/em> \u2014 t\u00e9rminos para los que no existe un equivalente claro o cuyo uso ya est\u00e1 arraigado internacionalmente.<\/p>\n\n\n\n

En ciberseguridad, casi todos los t\u00e9rminos caen en una zona gris inc\u00f3moda: t\u00e9cnicamente tienen traducci\u00f3n, pero usarla puede generar confusi\u00f3n, p\u00e9rdida de precisi\u00f3n o simplemente resultar rid\u00edcula para quien vive el d\u00eda a d\u00eda del sector.<\/p>\n\n\n\n

La clave est\u00e1 en preguntarse: \u00bfpara qui\u00e9n escribo?<\/strong> Un post t\u00e9cnico en un foro de hacking \u00e9tico no tiene el mismo p\u00fablico que un informe ejecutivo, una pol\u00edtica corporativa o un art\u00edculo de divulgaci\u00f3n. El idioma que usamos define qui\u00e9n puede entendernos \u2014 y eso, en seguridad, importa mucho.<\/a><\/p>\n\n\n\n

\n\n\n\n

10 ejemplos dificiles de traducir<\/h2>\n\n\n\n

A continuaci\u00f3n analizamos 10 t\u00e9rminos con sus traducciones propuestas, sus problemas y nuestra recomendaci\u00f3n pr\u00e1ctica.<\/p>\n\n\n\n

1. Safety vs. Security<\/h3>\n\n\n\n

Este es quiz\u00e1s el caso m\u00e1s parad\u00f3jico: dos palabras en ingl\u00e9s que en espa\u00f1ol convergen en una sola. Tanto safety<\/em> (seguridad funcional, proteger a las personas de los sistemas) como security<\/em> (ciberseguridad, proteger los sistemas de las personas) se traducen como “seguridad”<\/strong>.<\/a><\/p>\n\n\n\n

El resultado es una ambig\u00fcedad que puede tener consecuencias reales. \u00bfEstamos hablando de que el sistema no va a fallar y lastimar a alguien (safety<\/em>), o de que no va a ser hackeado (security<\/em>)? En contextos como infraestructura cr\u00edtica, plantas industriales o sistemas m\u00e9dicos, confundir los dos conceptos puede ser catastr\u00f3fico.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> Mantener los t\u00e9rminos en ingl\u00e9s cuando sea necesario distinguirlos, o aclarar expl\u00edcitamente: “seguridad funcional (safety)”<\/em> vs. “ciberseguridad (security)”<\/em>. El INCIBE y otros organismos ya reconocen esta distinci\u00f3n en sus glosarios oficiales.<\/a><\/p>\n\n\n\n

\n\n\n\n

2. In the Wild<\/h3>\n\n\n\n

Literalmente: “en la naturaleza” o “en el mundo real”. En ciberseguridad, este t\u00e9rmino describe una vulnerabilidad o exploit que ya est\u00e1 siendo utilizado activamente en ataques reales<\/strong>, no solo como prueba de concepto.<\/a><\/p>\n\n\n\n

La traducci\u00f3n directa “en la naturaleza” suena po\u00e9tica pero confusa. El NIST, en sus publicaciones traducidas al espa\u00f1ol, ha optado por mantener la frase en ingl\u00e9s o usar per\u00edfrasis como\u00a0“explotado activamente”<\/em>\u00a0u\u00a0“observado en ataques reales”<\/em>. Organismos como el INCIBE tambi\u00e9n la usan sin traducir en contextos t\u00e9cnicos.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> En textos t\u00e9cnicos, usar “in the wild”<\/em> (en cursiva) con una nota aclaratoria la primera vez: “in the wild (activo en ataques reales)”<\/em>. En textos divulgativos, la descripci\u00f3n es m\u00e1s clara que el t\u00e9rmino.<\/p>\n\n\n\n

\n\n\n\n

3. Weaponize<\/h3>\n\n\n\n

Aqu\u00ed tenemos un caso interesante de neologismo espont\u00e1neo<\/strong>. El t\u00e9rmino weaponize<\/em> significa convertir algo inofensivo en un arma o vector de ataque. En espa\u00f1ol circulan varias propuestas: “armamentizar”<\/em>, “militarizar”<\/em>, “convertir en arma”<\/em> \u2014 y cada vez m\u00e1s, el calco directo “weaponizar”<\/strong>.<\/p>\n\n\n\n

El uso de “weaponizar” ya aparece en posts t\u00e9cnicos de profesionales hispanohablantes y blogs especializados. Sin embargo, la RAE no lo ha adoptado. Las traducciones formales lo describen como “convertir en arma”<\/em> o “instrumentalizar para ataque”<\/em>.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> En textos t\u00e9cnicos entre pares, “weaponizar” es perfectamente comprensible y \u00e1gil. En documentos formales, jur\u00eddicos o corporativos, es preferible escribir “transformar en vector de ataque”<\/em> o “aprovechar como arma ofensiva”<\/em>.<\/p>\n\n\n\n

\n\n\n\n

4. Hardening<\/h3>\n\n\n\n

El hardening<\/em> es el proceso de fortalecer un sistema reduciendo su superficie de ataque: deshabilitar servicios innecesarios, aplicar configuraciones seguras, eliminar cuentas por defecto. La Wikipedia en espa\u00f1ol lo traduce como “endurecimiento”<\/strong>, aunque reconoce que el t\u00e9rmino t\u00e9cnico es hardening<\/em>.<\/p>\n\n\n\n

“Endurecimiento de sistemas” suena torpe pero es t\u00e9cnicamente correcto. En la pr\u00e1ctica, el sector habla de hardening<\/em> sin m\u00e1s. Incluso variantes como “hardenizaci\u00f3n” o “hardenizar” est\u00e1n ganando terreno en el espa\u00f1ol t\u00e9cnico.<\/a><\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong>\u00a0Usar\u00a0hardening<\/em>\u00a0en contextos t\u00e9cnicos es lo est\u00e1ndar. En pol\u00edticas de seguridad o comunicaciones a no t\u00e9cnicos, a\u00f1adir la descripci\u00f3n:\u00a0“hardening (proceso de fortalecimiento y reducci\u00f3n de superficie de ataque)”<\/em>. <\/a><\/p>\n\n\n\n

\n\n\n\n

5. Payload<\/h3>\n\n\n\n

En ciberseguridad, el payload<\/em> es la parte activa de un ataque<\/strong>: el c\u00f3digo que realmente ejecuta la acci\u00f3n maliciosa (cifrar archivos, abrir una puerta trasera (backdoor), robar credenciales) una vez que el vector de entrega ha tenido \u00e9xito.<\/a><\/p>\n\n\n\n

Las traducciones propuestas incluyen “carga \u00fatil”, “carga maliciosa” o simplemente “carga”. Ninguna de ellas ha desplazado al original. El problema es que “carga \u00fatil” tiene connotaciones positivas en otros contextos de ingenier\u00eda (cohetes, transmisiones de datos), lo que puede generar confusi\u00f3n.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> Payload<\/em> es uno de los t\u00e9rminos donde la resistencia a la traducci\u00f3n est\u00e1 m\u00e1s justificada. Su uso en espa\u00f1ol es pr\u00e1cticamente universal en el sector. En textos divulgativos, se puede explicar como “la carga maliciosa del ataque”<\/em>, pero sin renunciar al t\u00e9rmino t\u00e9cnico.<\/a><\/p>\n\n\n\n

\n\n\n\n

6. Hardcoded<\/h3>\n\n\n\n

Hardcoded<\/em>\u00a0hace referencia a valores, contrase\u00f1as o configuraciones\u00a0embebidas directamente en el c\u00f3digo fuente<\/strong>\u00a0de una aplicaci\u00f3n, en lugar de ser definidos externamente. Es un problema de seguridad frecuente: credenciales hardcodeadas que luego se exponen en repositorios p\u00fablicos o en binarios descompilados.<\/a><\/p>\n\n\n\n

Las traducciones disponibles incluyen “codificado de forma r\u00edgida”, “embebido en el c\u00f3digo” o “incrustado”. En la pr\u00e1ctica del sector en espa\u00f1ol se usa\u00a0hardcoded<\/em>\u00a0directamente, o se dice que algo est\u00e1\u00a0“hardcodeado”<\/em>. El uso t\u00e9cnico est\u00e1 tan arraigado que inventar una nueva palabra castellana resultar\u00eda artificial.<\/a><\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> En an\u00e1lisis de vulnerabilidades y c\u00f3digo, hardcoded<\/em> (o “hardcodeado” coloquialmente) es el est\u00e1ndar. En informes ejecutivos o comunicaciones de cumplimiento normativo, se recomienda “credenciales embebidas en el c\u00f3digo fuente”<\/em> para mayor claridad legal.<\/p>\n\n\n\n

\n\n\n\n

7. Fuzzing<\/h3>\n\n\n\n

El fuzzing<\/em> (o fuzz testing<\/em>) es una t\u00e9cnica de prueba de seguridad que consiste en enviar datos inv\u00e1lidos, inesperados o aleatorios a un programa para detectar comportamientos an\u00f3malos y vulnerabilidades. El t\u00e9rmino proviene de fuzzy<\/em> (difuso) y fue acu\u00f1ado por Bart Miller en 1988.<\/p>\n\n\n\n

No existe una traducci\u00f3n al espa\u00f1ol que haya ganado adopci\u00f3n. Se han propuesto “pruebas de datos aleatorios” o “pruebas de desaf\u00edo”, pero ninguna describe con precisi\u00f3n la t\u00e9cnica. En todo el material acad\u00e9mico y t\u00e9cnico en espa\u00f1ol, fuzzing<\/em> aparece sin traducci\u00f3n.<\/a><\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> Fuzzing<\/em> es un t\u00e9rmino t\u00e9cnico sin equivalente funcional en espa\u00f1ol. Usarlo directamente es lo correcto, con una breve definici\u00f3n la primera vez que aparezca. Este es uno de los casos donde intentar traducir solo a\u00f1ade confusi\u00f3n.<\/p>\n\n\n\n

\n\n\n\n

8. Penetration Testing<\/h3>\n\n\n\n

Las pruebas de penetraci\u00f3n<\/em> o pentesting<\/em> consisten en simular ataques reales controlados para identificar vulnerabilidades en sistemas antes de que los atacantes lo hagan. Aqu\u00ed tenemos un caso de \u00e9xito parcial en la traducci\u00f3n<\/strong>: “pruebas de penetraci\u00f3n” es la versi\u00f3n oficial y est\u00e1 ampliamente reconocida.<\/p>\n\n\n\n

La iron\u00eda es que “penetration testing” en ingl\u00e9s tambi\u00e9n genera incomodidad en presentaciones corporativas por sus connotaciones extraling\u00fc\u00edsticas. En espa\u00f1ol, “pruebas de penetraci\u00f3n” arrastra el mismo problema. Por eso, en contextos formales muchos profesionales prefieren “auditor\u00eda de seguridad ofensiva” o simplemente “pentesting”.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> Este es uno de los ejemplos m\u00e1s equilibrados. La traducci\u00f3n existe, funciona y es reconocida institucionalmente. Se recomienda usar “pruebas de penetraci\u00f3n (pentesting)”<\/em> la primera vez y luego alternar seg\u00fan el contexto. En certificaciones y comunicaciones formales, la traducci\u00f3n es preferible.<\/a><\/p>\n\n\n\n

\n\n\n\n

9. Threat Actor<\/h3>\n\n\n\n

El threat actor<\/em> es cualquier individuo, grupo u organizaci\u00f3n que lleva a cabo acciones maliciosas con el objetivo de comprometer sistemas o datos. En espa\u00f1ol conviven varias traducciones: “actor de amenaza”<\/strong>, “actor malicioso”<\/strong>, “agente de amenaza”<\/strong> o “agente malicioso”<\/strong>.<\/p>\n\n\n\n

Ninguna versi\u00f3n domina claramente. El INCIBE, el CCN y organismos oficiales han hecho esfuerzos por estandarizar el vocabulario, pero la fragmentaci\u00f3n persiste.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> Aqu\u00ed la traducci\u00f3n s\u00ed es necesaria y funciona bien. “Actor de amenaza” o “actor malicioso” son opciones v\u00e1lidas y comprensibles. Elegir una y ser consistente dentro del mismo documento es lo m\u00e1s importante.<\/p>\n\n\n\n

\n\n\n\n

10. Compromise<\/h3>\n\n\n\n

En espa\u00f1ol, compromise<\/em> sufre un falso amigo parcial<\/strong>: en ingl\u00e9s coloquial significa llegar a un acuerdo, pero en ciberseguridad significa algo opuesto: que un sistema ha sido vulnerado, infiltrado o tomado por un atacante<\/strong>.<\/p>\n\n\n\n

“Comprometer un sistema” es ya una expresi\u00f3n completamente incorporada al espa\u00f1ol t\u00e9cnico de seguridad. Los documentos del INCIBE, el NIST en espa\u00f1ol y pr\u00e1cticamente toda la literatura t\u00e9cnica hispanohablante usan “comprometido” para describir un sistema que ha sido vulnerado.<\/p>\n\n\n\n

Recomendaci\u00f3n:<\/strong> “Comprometido” y “comprometer” son traducciones perfectamente consolidadas. Sin embargo, en textos que puedan llegar a audiencias no t\u00e9cnicas, conviene a\u00f1adir contexto: “un sistema comprometido (infiltrado o controlado por el atacante)”<\/em>, para evitar el malentendido con el significado coloquial de la palabra.<\/p>\n\n\n\n

\n\n\n\n

Principios para decidir cu\u00e1ndo traducir<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

El an\u00e1lisis de estos t\u00e9rminos revela patrones claros que pueden guiar la decisi\u00f3n:<\/p>\n\n\n\n

Criterio<\/th>Conservar en ingl\u00e9s cuando …<\/th>Traducir al espa\u00f1ol cuando …<\/th><\/tr><\/thead>
Equivalencia sem\u00e1ntica<\/strong><\/td>No existe traducci\u00f3n precisa (fuzzing<\/em>, payload<\/em>)<\/td>La traducci\u00f3n captura el significado completo (pruebas de penetraci\u00f3n<\/em>, actor de amenaza<\/em>)<\/td><\/tr>
Audiencia<\/strong><\/td>T\u00e9cnicos, analistas, pentesters<\/td>Directivos, abogados, usuarios finales, estudiantes<\/td><\/tr>
Contexto del documento<\/strong><\/td>Informes t\u00e9cnicos, foros, an\u00e1lisis de malware<\/td>Pol\u00edticas corporativas, documentos legales, materiales educativos<\/td><\/tr>
Adopci\u00f3n en el sector<\/strong><\/td>T\u00e9rmino ya “naturalizado” en el espa\u00f1ol t\u00e9cnico (hardcoded<\/em>, hardening<\/em>)<\/td>Traducci\u00f3n aceptada institucionalmente y sin ambig\u00fcedad<\/td><\/tr>
Riesgo de confusi\u00f3n<\/strong><\/td>La traducci\u00f3n genera ambig\u00fcedad (safety<\/em> vs. security<\/em>)<\/td>El anglicismo excluye a audiencias no especializadas<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

Reflexi\u00f3n final: la accesibilidad como argumento de seguridad<\/h2>\n\n\n\n

El debate sobre traducir o no la terminolog\u00eda de ciberseguridad no tiene una respuesta binaria porque el problema no es binario. Los datos revelan un patr\u00f3n claro: los t\u00e9rminos que se traducen bien se traducen solos<\/strong> (“comprometido”, “vulnerabilidad”, “cifrado”), mientras que los que resisten la traducci\u00f3n lo hacen por razones leg\u00edtimas de precisi\u00f3n, concisi\u00f3n o ausencia de equivalente funcional. La comunidad hispanohablante ha desarrollado org\u00e1nicamente un sistema h\u00edbrido que funciona: un espa\u00f1ol t\u00e9cnico fluido salpicado de anglicismos espec\u00edficos, donde cada t\u00e9rmino ocupa el nicho que mejor cumple su funci\u00f3n comunicativa.<\/p>\n\n\n\n

Lo que s\u00ed es urgente es reconocer que este sistema funciona para profesionales pero falla para el p\u00fablico general. Mientras el sector de ciberseguridad puede operar c\u00f3modamente en spanglish t\u00e9cnico, la concienciaci\u00f3n necesita un espa\u00f1ol limpio, directo y libre de anglicismos innecesarios<\/strong>. El verdadero desaf\u00edo no es decidir si traducir payload<\/em> o fuzzing<\/em> \u2014eso lo resuelve el contexto y la audiencia\u2014, sino garantizar que cuando una amenaza real afecta a personas reales, el lenguaje de la defensa sea tan comprensible como el del ataque.<\/p>\n\n\n\n

\n\n\n\n

Este art\u00edculo refleja el uso real de la terminolog\u00eda en la comunidad hispanohablante de seguridad ofensiva y no pretende ser una gu\u00eda normativa definitiva, sino un punto de partida para la discusi\u00f3n.<\/em><\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Imagina que recibes un reporte y lees: “El actor de amenaza utiliz\u00f3 un payload hardcodeado para comprometer el sistema aprovechando una vulnerabilidad explotada in the wild, despu\u00e9s de haber realizando fuzzing sobre el endpoint.” \u00bfLo entendiste todo? Seguramente s\u00ed, si llevas tiempo en el gremio. Pero ahora imagina que ese mismo p\u00e1rrafo llega al director de […]<\/p>\n","protected":false},"author":6,"featured_media":1903,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,4,5],"tags":[],"class_list":["post-1890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pentest-2","category-pentest","category-seguridad-de-la-informacion"],"_links":{"self":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts\/1890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/comments?post=1890"}],"version-history":[{"count":7,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts\/1890\/revisions"}],"predecessor-version":[{"id":1902,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/posts\/1890\/revisions\/1902"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/media\/1903"}],"wp:attachment":[{"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/media?parent=1890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/categories?post=1890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hacking.onesec.mx\/index.php\/wp-json\/wp\/v2\/tags?post=1890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}