Capítulo 10 — Ética y seguridad en la ingeniería
Mapa de la lección
Lección 10 publicada. Mapa, ejemplo, EX028.
flowchart TD
N0["Resultados de aprendizaje"]
N1["10.1 Deberes profesionales"]
N2["10.2 Seguridad funcional y ciberseguridad"]
N3["10.3 Pruebas autorizadas y divulgación"]
N4["10.4 Legislación y regulación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX028"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["10.1 Deberes profesionales"]
N2["10.2 Seguridad funcional y ciberseguridad"]
N3["10.3 Pruebas autorizadas y divulgación"]
N4["10.4 Legislación y regulación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX028"]
[Resultados de aprendizaje]
|
v
[10.1 Deberes profesionales]
|
v
[10.2 Seguridad funcional y ciberseguridad]
|
v
[10.3 Pruebas autorizadas y divulgación]
|
v
[10.4 Legislación y regulación]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX028]
Resultados de aprendizaje
Usted será capaz de (1) aplicar la ética profesional de la ingeniería a los sistemas de IA; (2) distinguir la seguridad funcional (daño accidental) de la ciberseguridad (daño intencionado) y mostrar cómo interactúan; (3) aplicar las reglas de las pruebas autorizadas y la divulgación responsable; y (4) reconocer obligaciones legales como las del Reglamento de IA de la UE para los sistemas de alto riesgo.
10.1 Deberes profesionales
Los códigos de ética de la ingeniería anteponen la seguridad, la salud y el bienestar públicos, exigen honestidad sobre las capacidades y los límites, y exigen competencia. En la IA, esto significa no exagerar lo que puede hacer un modelo, documentar los modos de fallo conocidos y negarse a desplegar cuando el riesgo es inaceptable. Estos deberes se aplican en los momentos corrientes, no solo en los dramáticos: una diapositiva que redondea a la baja una tasa de fallos al amanecer del 9 % hasta «alrededor del 2 %», una demostración que oculta las condiciones en que el modelo falla o un plazo que tienta a un equipo a saltarse la revisión de seguridad. La competencia incluye conocer los límites de la propia pericia y pedir ayuda, por ejemplo a un ingeniero de seguridad ferroviaria, cuando una decisión queda fuera de ellos.
10.2 Seguridad funcional y ciberseguridad
La ingeniería de seguridad funcional se ocupa de los fallos accidentales; la ciberseguridad, de los ataques deliberados. En la IA interactúan: una entrada adversarial puede causar un fallo de seguridad funcional (un defecto del carril no detectado), y un mecanismo de seguridad funcional (el paso a la inspección manual) puede usarse de forma abusiva para causar una denegación de servicio. El AI RMF del NIST (AI 100-1) incluye seguro (safe) y protegido y resiliente (secure and resilient) entre las características de una IA confiable y subraya que deben gestionarse conjuntamente.
Gestionarlas conjuntamente significa un único análisis de peligros que pregunte tanto qué podría fallar como qué podría hacer fallar alguien. El paso a la inspección manual es seguro frente a los accidentes, pero un atacante capaz de provocarlo repetidamente podría agotar a los inspectores y retrasar el trabajo real.
10.3 Pruebas autorizadas y divulgación
Pruebe solo sistemas que sean suyos o para los que tenga permiso escrito, dentro de un alcance y un plazo definidos. Nunca lance ataques contra servicios públicos de IA sin autorización; las condiciones de servicio suelen prohibirlo. Cuando encuentre una vulnerabilidad en el producto de otra persona, comuníquela en privado al fabricante y acuerden un calendario antes de publicarla (divulgación coordinada). Mantenga los datos de prueba sintéticos o debidamente gobernados; nunca extraiga ni publique datos personales. El permiso escrito indica quién puede probar, qué, cuándo y con qué métodos.
10.4 Legislación y regulación
El Reglamento (UE) 2024/1689 (el Reglamento de IA) clasifica algunos sistemas de IA como de alto riesgo, entre ellos los componentes de seguridad de infraestructuras críticas, y exige gestión de riesgos, gobernanza de datos, documentación técnica, registro de eventos, supervisión humana, y precisión, solidez y ciberseguridad (artículo 15). Las obligaciones se aplican por etapas de 2025 a 2027. Los ingenieros deben saber si su sistema puede entrar en una categoría regulada y recurrir a expertos jurídicos; este libro ofrece orientación, no asesoramiento jurídico. Incluso antes del asesoramiento jurídico, un ingeniero puede preparar la evidencia que necesitaría un sistema regulado: un registro de riesgos, la documentación de los conjuntos de datos, registros de las decisiones y constancia de la revisión humana. Esos registros son una buena práctica de todos modos, y reunirlos pronto evita tener que reconstruir más tarde la historia de un sistema con prisas.
10.5 Ejemplo resuelto (caso sintético de NRS)
Un directivo pidió a Sam que subiera el umbral de alerta de TrackEye para reducir las falsas alarmas antes de una demostración. Sam calculó que los falsos negativos subirían del 2 % al 5 % con datos diurnos. Sam documentó el compromiso, se negó a cambiar el umbral de producción sin una revisión de seguridad y propuso una configuración solo para la demostración, claramente etiquetada como tal. Sam señaló además que TrackEye, como componente de seguridad de una infraestructura ferroviaria, puede ser de alto riesgo según el Reglamento de IA, y lo remitió a revisión jurídica. La configuración de demostración cumplió el objetivo del directivo sin tocar el sistema que inspecciona la vía real.
10.6 Errores y límites
- Tratar la ética como algo separado de las decisiones técnicas.
- Probar servicios de IA de terceros sin permiso.
- Ocultar compromisos de seguridad en cambios de configuración.
La ética separada del trabajo técnico tiende a aparecer solo en documentos de políticas, mientras que las decisiones reales se toman en los umbrales y en los planes de prueba. Probar un servicio público de IA sin permiso puede infringir la ley incluso con buenas intenciones. Un cambio de umbral que cambia en silencio defectos no detectados por menos alarmas es una decisión de seguridad tomada sin las personas responsables de la seguridad; la regla de Sam es que cualquier cambio que afecte a las tasas de fallos de detección pase por revisión con sus números a la vista.
Ejercicios — capítulo 10
- EX028 — Seguridad funcional y ciberseguridad. Dé un ejemplo en NRS en que un ataque cause un fallo de seguridad funcional y otro en que se abuse de un mecanismo de seguridad funcional. Rúbrica: 3 = ambos verosímiles; 2 = uno; 1 = confuso; 0 = nada.
- EX029 — Divulgación. Descubre que el modelo alojado de un proveedor filtra los prompts de otros clientes. Enumere los pasos que da. Rúbrica: 3 = detenerse, conservar la evidencia mínima, informe privado, calendario acordado, no publicar datos; 2 = parcial; 1 = vago; 0 = publicar o explotar.
- EX030 — Reglamento de IA. Nombre cuatro obligaciones de los sistemas de IA de alto riesgo. Rúbrica: 3 = cuatro entre gestión de riesgos, gobernanza de datos, documentación, registro de eventos, transparencia, supervisión humana, precisión/solidez/ciberseguridad; 2 = tres; 1 = una o dos; 0 = nada.
Síntesis del capítulo
La ética en la ingeniería de IA es concreta: límites honestos, seguridad funcional y ciberseguridad gestionadas conjuntamente, pruebas autorizadas, divulgación coordinada y conciencia de las obligaciones legales de los sistemas de alto riesgo.
Siga estudiando — capítulo 10 de 50
← Capítulo 09 (borrador) · Índice de capítulos del curso · Capítulo 11 (borrador) →