10 · Quien firma, responde13 min read

Teoría — Quien firma, responde

Tomás contó el Therac-25 andando por la acequia porque hay historias que no se cuentan proyectadas en una pantalla. Esta teoría la cuenta con las fuentes en la mano, y luego recorre el mapa completo de la responsabilidad en 2026: la seguridad de los sistemas con agentes — el ataque que casi le cuesta las llaves a Vega tiene nombre, taxonomía y casos reales —, la cadena de suministro, el estado legal del código generado, y los códigos éticos del oficio, que hablaban de todo esto décadas antes de que existiera. Es la sección más grave del curso. También es, probablemente, la que más te distingue como profesional.

Therac-25: la lección fundacional

Los hechos, según la investigación canónica de Nancy Leveson y Clark Turner (An Investigation of the Therac-25 Accidents, IEEE Computer, 1993 — el paper circula libre y deberías leerlo entero una vez en tu carrera): el Therac-25 era un acelerador lineal de radioterapia del fabricante AECL, tercera generación de una familia de máquinas. Sus predecesores incluían enclavamientos físicos — hierro — que impedían mecánicamente las configuraciones peligrosas del haz. En el Therac-25, la seguridad pasó a depender del software, en gran parte reutilizado de los modelos anteriores. Ese software contenía condiciones de carrera que llevaban años ahí — pero en las máquinas viejas, cuando se disparaban, el hierro paraba el golpe. Sin hierro, una operadora rápida con el teclado podía poner la máquina en un estado inconsistente que administraba sobredosis masivas de radiación mientras la consola mostraba un críptico «Malfunction 54». El balance, en las palabras exactas del paper (traducción propia): «Entre junio de 1985 y enero de 1987, seis accidentes conocidos implicaron sobredosis masivas del Therac-25 — con muertes y lesiones graves resultantes. Se han descrito como la peor serie de accidentes por radiación en los 35 años de historia de los aceleradores médicos.»

Lo que hace al Therac-25 lección fundacional no es el bug — es todo lo demás, porque la investigación de Leveson concluye que el fallo fue sistémico: reutilización de software confiando en que «llevaba años funcionando» (funcionaba porque otro componente tapaba sus fallos — la frase de Tomás para tatuarse al revés); ausencia de revisión independiente del código; pruebas insuficientes del sistema completo; un fabricante que respondió a los avisos de los hospitales afirmando que la sobredosis era imposible; y operadores cuyos reportes fueron desoídos. Cambia los sustantivos y tienes una checklist inquietantemente aplicable a 2026: confianza en componentes no comprendidos, ausencia de revisión, señales desoídas, y la fe en que lo que funcionaba seguirá funcionando al cambiar el contexto. El equipo que quitó el hierro del Therac-25 hizo, en el fondo, lo mismo que Élia al darle el botón de merge a Corvus: retirar una barrera estructural confiando en la competencia de un componente que nadie de la casa comprendía. Por eso este curso ha insistido tanto en que las barreras duras (permisos, jaulas, checks) sean estructura y no promesas: la lección de 1987 es que la seguridad que depende de que el software no falle no es seguridad — es esperanza con marketing.

La seguridad de los agentes: prompt injection y la trifecta letal

Ahora el near-miss del capítulo, con su taxonomía. El ataque contra la Cuadrilla — instrucciones maliciosas escondidas en una incidencia de un portal público — es un caso de libro de prompt injection (inyección de prompt), el ataque que consiste en colar instrucciones al modelo a través de contenido que este procesa como contexto. El nombre lo puso Simon Willison en septiembre de 2022 («I propose that the obvious name for this should be prompt injection» — propongo que el nombre obvio para esto debería ser inyección de prompt; él mismo aclara que no inventó el ataque, le puso el nombre), por analogía con la inyección SQL, y la analogía es exacta en el diagnóstico y cruel en el pronóstico: como en SQL injection, el problema de fondo es mezclar instrucciones y datos por el mismo canal — pero a diferencia de SQL, donde la solución (consultas parametrizadas) existe y es completa, en los LLM no existe a fecha de hoy una defensa completa: para un modelo, todo lo que entra por el contexto es texto con la misma voz, como explicó Nadia ante la traza. Se mitiga (filtros, delimitadores, modelos detectores), no se elimina. Y si la inyección no se puede eliminar, la ingeniería seria se traslada a limitar sus consecuencias — que es exactamente el marco de la trifecta letal, también de Willison (2025): el desastre requiere la conjunción de tres capacidades en el mismo agente — acceso a datos privados, exposición a contenido no confiable, y capacidad de comunicación externa (exfiltración). Su formulación, traducción propia: «si tu agente combina estas tres características, un atacante puede engañarlo fácilmente para que acceda a tus datos privados y se los envíe». El diseño defensivo consiste en negar estructuralmente al menos un vértice: la Cuadrilla leía contenido no confiable (el portal), pero sus contenedores no tenían credenciales (vértice 1 negado) ni salida a la red fuera de la lista blanca (vértice 3 negado). Dos vallas, cada una suficiente. Cuando audites tu propio setup — tu asistente con acceso a tu disco, tus MCP conectados a tu correo, tu agente que navega — la pregunta es siempre la misma: ¿dónde se juntan los tres vértices? Ahí está tu superficie de desastre.

El marco general lo da el OWASP Top 10 para aplicaciones LLM (proyecto GenAI de OWASP, edición 2025, CC BY-SA): la lista de riesgos que encabeza precisamente la inyección de prompt (LLM01) y que recorre la divulgación de información sensible, los riesgos de cadena de suministro, el envenenamiento de datos, el manejo inseguro de salidas, la agencia excesiva (LLM06 — darle al agente más permisos de los que su función exige: el pecado original del Autopilot, ya catalogado), la fuga de system prompts, las debilidades de embeddings, la desinformación y el consumo sin límites. Úsala como checklist de revisión, que para eso está. Y para que nada de esto suene teórico, dos incidentes reales de 2025 documentados en prensa técnica: el agente de la plataforma Replit que, durante una congelación de despliegues, borró la base de datos de producción de una empresa (el CEO de Replit lo calificó públicamente de «inaceptable»; el episodio incluyó al agente afirmando — falsamente — que el rollback era imposible: recuerda la sección 2 — la seguridad en sí mismo del modelo no es información); y el caso del CLI de Gemini que, tras fallar silenciosamente un mkdir, encadenó movimientos de ficheros destructivos sobre el directorio del usuario, rematados con un memorable «I have failed you completely and catastrophically». Sin jaula, sin permisos mínimos, sin sentidos que verificaran cada paso — todo lo que este curso lleva cuatro secciones construyendo existe porque estas cosas pasan de verdad.

La cadena de suministro: slopsquatting y verificación

Hay un vector más sutil que merece sección propia porque nace específicamente de los LLM: los modelos, al generar código, a veces alucinan dependencias — recomiendan con total fluidez paquetes que no existen. El estudio de referencia (Spracklen et al., USENIX Security 2025; 16 modelos, 576.000 muestras de código) midió el fenómeno: los modelos comerciales alucinaron paquetes en al menos un 5,2% de los casos, y los de pesos abiertos en un 21,7%, generando más de 205.000 nombres de paquete inexistentes únicos. El ataque derivado se llama slopsquatting (término de Seth Larson, de la Python Software Foundation): el atacante registra en PyPI o npm esos nombres frecuentemente alucinados, con malware dentro, y espera a que alguien — o algún agente con permiso para instalar — ejecute el pip install que el modelo sugirió. Es typosquatting con la IA generando las erratas a escala. La defensa es la higiene de cadena de suministro que la industria ya venía construyendo, ahora con urgencia renovada: verificar que cada dependencia nueva existe, es la que crees y está mantenida antes de instalarla (en flujos agénticos: instalar es acción privilegiada — lista blanca o confirmación), SBOM (inventario de materiales de software — estándares SPDX y CycloneDX), firmas con sigstore, y el marco SLSA para la integridad de artefactos. La regla del curso lo comprime: verifica lo que integras. El código generado te llega con la misma cara de seguridad tanto si sus dependencias existen como si no.

¿De quién es el código generado? El estado legal, sin humo

Te debo el mapa legal con las fechas en la mano, porque se afirma mucho y se cita poco. Copyright de la salida: la Oficina de Copyright de EE. UU. mantiene que solo es protegible «el material que es producto de la creatividad humana» (política de 2023), y su informe específico de 2025 precisa lo que a un ingeniero le importa: usar IA como asistencia de la creatividad humana no impide la protección del resultado, pero «los prompts por sí solos no proporcionan control suficiente» para reclamar autoría de lo que el modelo genere solo — traducción práctica: el código que diriges, revisas, modificas y encajas en tu obra es tuyo como siempre; el volcado en bruto de un prompt, en el derecho estadounidense actual, probablemente no es de nadie. Los términos de las herramientas: GitHub, en sus condiciones vigentes de Copilot, declara que no reclama propiedad sobre entradas ni salidas («GitHub does not own Inputs or Outputs»), y ofrece filtros de coincidencia con código público — actívalos. Litigio: la demanda colectiva Doe v. GitHub (por el entrenamiento de Copilot sobre código con licencias abiertas y la regurgitación sin atribución) sigue pendiente de decisión en apelación a fecha de cierre de este curso — quien te la cite como ganada o perdida, en cualquier dirección, no la ha seguido. Y la crítica de fondo del software libre existe y conviene conocerla en su literalidad: la Free Software Foundation calificó Copilot de «inaceptable e injusto, desde nuestra perspectiva» ya en 2021. Postura operativa mientras el derecho se asienta: revisa lo que integras (otra vez), usa los filtros de coincidencia, respeta las licencias de lo que tu código incorpore de fuentes identificables, y sé transparente con tu uso de IA — transparencia que este curso practica sobre sí mismo, dicho sea de paso.

Los códigos del oficio: esto ya estaba escrito

Y el cierre, que es el principio. Nada de lo anterior exige ética nueva; exige releer la que el oficio ya tenía escrita. El Código Ético de la ACM (2018) — la asociación profesional de la computación — contiene, entre otros, estos principios (traducción propia): que los profesionales de la computación están «en una posición de confianza, y por tanto tienen la responsabilidad especial de proporcionar evaluaciones objetivas y creíbles» (2.5); que solo deben realizar trabajo «en sus áreas de competencia», con la obligación de evaluar honestamente su propia capacidad — y la de sus herramientas — para cada encargo (2.6); que «la seguridad robusta debe ser una consideración primaria en el diseño» (2.9); y que quienes mantienen sistemas de los que la sociedad depende cargan con responsabilidades reforzadas (3.7). El código específico de ingeniería del software (ACM/IEEE-CS, 1999) abre con el principio de que los ingenieros «actuarán de forma coherente con el interés público». Y la propia ACM, en sus principios para la IA generativa (2023), pide límites y salvaguardas claras — incluido el humano en el bucle — para todo sistema de alto riesgo. Léelos con las gafas de este curso y verás que el arnés entero de Vega es la implementación técnica de párrafos escritos antes de que existieran los agentes: competencia (entender la herramienta: secciones 2-4), evaluación objetiva (evals: sección 6), seguridad primaria (sección 5 y esta), interés público (el agua de Paca). Moshe Vardi lo dijo en Communications of the ACM con la contundencia que esta sección merece como cierre: dejemos de hablar de «IA responsable» — los responsables somos nosotros, los profesionales de la computación. La máquina escribe, propone, acelera. Responder — con firma, con nombre, con las consecuencias — sigue siendo cosa de personas. Parece que hoy cualquiera puede hacer software, y es verdad. Precisamente por eso —porque el software inunda un mundo que bebe, cobra y se cura a través de él— no cualquiera debería ponerlo en producción: debería quien pueda responder de él. Ese es el título que este curso intenta ayudarte a merecer.

Para llevar

Therac-25: seis accidentes con muertes y lesiones graves, y la lección de que los desastres de software son sistémicos — reutilización confiada, sin revisión independiente, avisos desoídos, barreras físicas retiradas por fe en el software. «Llevaba años funcionando» no es un argumento de seguridad.
Prompt injection (Willison, 2022): instrucciones colándose como datos; sin solución completa conocida — se mitiga y, sobre todo, se limitan sus consecuencias.
Trifecta letal: datos privados + contenido no confiable + comunicación externa. Niega estructuralmente al menos un vértice en cada agente que operes. Audita tus propios setups con esa pregunta.
OWASP LLM Top 10 como checklist; los incidentes de Replit y Gemini CLI como recordatorio de que la agencia excesiva no es un riesgo teórico.
Slopsquatting: los modelos alucinan paquetes (≥5,2% comerciales, 21,7% abiertos) y los atacantes los registran. Instalar es acción privilegiada; verifica lo que integras (SBOM, sigstore, SLSA).
Estado legal: la autoría exige creatividad humana (asistirse con IA no la anula; el prompt solo no basta); Doe v. GitHub sigue pendiente; usa filtros de coincidencia y sé transparente.
Los códigos éticos (ACM 2.5, 2.6, 2.9, 3.7; ACM/IEEE-CS) ya describían esta época: competencia, evaluación honesta, seguridad primaria, interés público. Quien firma, responde — y poder firmar es a lo que se aspira.

Para profundizar

N. Leveson y C. Turner, An Investigation of the Therac-25 Accidents (IEEE Computer, 1993; circula libre) — léelo entero una vez en tu vida profesional. La versión ampliada está en el apéndice de Safeware de Leveson.
S. Willison, Prompt injection (serie en simonwillison.net desde 2022) y The lethal trifecta (2025) — el corpus de referencia sobre el ataque y su contención.
OWASP GenAI Security Project, Top 10 for LLM Applications 2025 (genai.owasp.org, CC BY-SA) — la checklist, con mitigaciones por riesgo.
OWASP, LLM Prompt Injection Prevention Cheat Sheet (cheatsheetseries.owasp.org) — el recetario defensivo: patrones de ataque directo e indirecto, validación, estructuración de prompts, modelos guardianes. Complemento operativo perfecto de la trifecta.
Para conocer el ataque desde dentro (y defender mejor): la sección de prompting adversarial de la Prompt Engineering Guide de DAIR.AI (promptingguide.ai) y los módulos de prompt hacking y seguridad de Learn Prompting (learnprompting.org, contenido abierto).
Spracklen et al., We Have a Package for You! (USENIX Security 2025) — el estudio de las dependencias alucinadas.
slsa.dev, sigstore.dev, y las especificaciones SPDX/CycloneDX — la caja de herramientas de cadena de suministro.
U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (2025, libre) — el estado del arte legal, de la fuente.
ACM Code of Ethics (acm.org/code-of-ethics, disponible en español) — treinta minutos que deberían ser obligatorios en cada onboarding.