Inteligencia Artificial — Arquitectura, Escalamiento, Gobierno, Seguridad, Privacidad, Riesgos y Uso Responsable

Q1. ¿Qué es la arquitectura de una solución de IA y en qué se diferencia de una aplicación tradicional?

Es el diseño de todos los componentes que permiten llevar un modelo de IA desde los datos hasta el usuario final: datos, plataforma de entrenamiento, servicio de inferencia, aplicación y capas transversales de MLOps, seguridad, observabilidad y gobernanza. A diferencia de una aplicación tradicional (código determinista y estático), un sistema de IA depende de datos y modelos que cambian en el tiempo (drift), no es completamente determinista y exige controles de IA responsable, trazabilidad de modelos y gestión continua del ciclo de vida.

Q2. ¿Cuáles son las capas de una arquitectura de referencia de IA?

• Capa de datos: ingesta (batch/streaming), almacenamiento (lakehouse), feature store, bases vectoriales, linaje y calidad de datos.
• Plataforma ML/LLM: pipelines de entrenamiento, experiment tracking, tuning, registro de modelos (model registry) y gestión de artefactos.
• Capa de serving/inferencia: APIs en tiempo real, inferencia batch y streaming, motores de servicio (Triton, vLLM), gateways de IA.
• Capa de aplicación: integración con canales de negocio, orquestación (agentes, RAG), interfaces de usuario.
• Capas transversales: MLOps/LLMOps (CI/CD/CT), observabilidad, seguridad, privacidad, gobernanza y gestión de riesgos.

Q3. ¿Qué es una feature store y por qué es importante?

Es un repositorio centralizado de características (features) reutilizables, con versiones, linaje y consistencia entre entrenamiento y producción (offline store para entrenar, online store para servir con baja latencia). Evita el sesgo de entrenamiento-servicio (training/serving skew), acelera nuevos modelos y mejora la gobernanza de datos. Ejemplos: Feast, SageMaker Feature Store, Vertex AI Feature Store.

Q4. ¿Qué patrones existen para incorporar LLMs en una aplicación?

• Prompting / few-shot: rápido y barato, sin entrenamiento; limitado por el contexto y el conocimiento del modelo.
• RAG: añade conocimiento propio y actualizado en tiempo de consulta; reduce alucinaciones y facilita citar fuentes.
• Fine-tuning / LoRA / destilación: adapta el modelo a tareas o estilos específicos con datos propios; mayor costo y esfuerzo de MLOps.
• Agentes con herramientas: el modelo orquesta acciones (APIs, consultas, transacciones); requiere controles de seguridad estrictos (least privilege, aprobación humana).

Q5. ¿Qué es RAG y cuándo conviene usarlo?

Retrieval-Augmented Generation: combina un buscador semántico (embeddings + base vectorial) con un LLM. Flujo: ingesta y chunking de documentos, generación de embeddings, recuperación por similitud, re-ranking y generación de la respuesta con citas. Conviene cuando se necesita conocimiento privado, dinámico o verificable (normativa, catálogos, documentación interna) sin reentrenar el modelo. Clave: control de acceso por permisos en la recuperación y evaluación de calidad (evals de grounding).

Q6. ¿Qué diferencia hay entre MLOps y LLMOps?

MLOps cubre el ciclo de vida de modelos clásicos (datos, entrenamiento, despliegue, monitoreo, reentrenamiento). LLMOps añade prácticas propias de modelos fundacionales: gestión y versionado de prompts, evaluaciones automáticas y humanas (evals), guardrails de entrada/salida, observabilidad de tokens y costos, gestión de contexto/RAG y control de versiones del modelo del proveedor.

Q7. ¿Cómo se elige entre modelos por API (propietarios) y modelos abiertos auto-hospedados?

Criterios: privacidad y cumplimiento (¿los datos pueden salir de la organización?), costo por token vs costo de infraestructura GPU, latencia, control de versiones, capacidad de personalización y esfuerzo operativo. Patrón común: arquitectura híbrida con enrutamiento por caso de uso (modelos pequeños locales para tareas simples; API para tareas complejas), evitando dependencia única de un proveedor (multi-model / model routing).

Q8. ¿Qué rol cumple una plataforma como SageMaker, Vertex AI o Azure ML?

Son plataformas gestionadas end-to-end que integran preparación de datos, entrenamiento, tuning de hiperparámetros, registro de modelos, despliegue (endpoints en tiempo real y batch) y monitoreo, con integración a IAM, cifrado y servicios de observabilidad del cloud. Reducen el esfuerzo de construir y escalar infraestructura de ML y aportan controles de seguridad, auditoría y gobernanza nativos de la nube (AWS, GCP, Azure respectivamente).

Q9. ¿Cómo se diseña la observabilidad de un sistema de IA?

Cuatro planos: (1) calidad de datos (esquema, nulos, distribuciones); (2) modelo (performance, drift de datos y concepto, sesgo por subgrupos); (3) sistema (latencia p50/p95/p99, throughput, errores, utilización GPU, costo por inferencia); (4) negocio (KPIs del caso de uso). Para LLM se añade: tokens, TTFT, tasa de bloqueos de guardrails, calidad de respuestas y trazas de prompts con protección de datos. Herramientas: CloudWatch/Grafana, Evidently, Langfuse/LangSmith.

Q10. ¿Cómo se documenta la arquitectura de un sistema de IA para efectos de auditoría y gobernanza?

Con artefactos trazables: diagramas de arquitectura y flujo de datos, model cards y data cards, inventario/registro del sistema de IA, decisiones de diseño documentadas (ADRs), linaje de datos, versión del modelo y del dataset, resultados de evaluaciones (rendimiento, sesgo, robustez) y mapeo a controles de referencia (Anexo A de ISO/IEC 42001, NIST AI RMF). Esta evidencia es exactamente lo que un auditor o regulador solicita.

Q11. ¿Cómo se escala el entrenamiento de modelos?

Por datos (más volumen y mejor calidad, data augmentation), por cómputo (multi-GPU/multi-nodo con paralelismo de datos, tensor y pipeline; FSDP, DeepSpeed, Horovod) y por técnicas de eficiencia (mixed precision, gradient checkpointing, acumulación de gradientes). También se escala con transfer learning / fine-tuning sobre modelos preentrenados en lugar de entrenar desde cero.

Q12. ¿Cómo se escala la inferencia en producción?

Con réplicas stateless detrás de un balanceador, autoscaling por métricas reales (utilización GPU, profundidad de cola, latencia), batching dinámico, caché (respuestas y embeddings) y, si aplica, compartición de GPU (MIG, time-slicing). Escalado horizontal para throughput; escalado vertical (GPU más grande) solo cuando el modelo no cabe en una GPU o la latencia lo exige.

Q13. ¿Qué técnicas reducen costo y latencia de inferencia con LLMs?

• Cuantización (INT8/INT4, GPTQ, AWQ): menos memoria y más velocidad con pérdida mínima de calidad.
• Motores de serving optimizados (vLLM con PagedAttention, TensorRT-LLM) y KV cache.
• Decodificación especulativa y modelos destilados o más pequeños para tareas acotadas.
• Semantic caching de respuestas frecuentes y optimización de prompts (menos tokens).

Q14. ¿Qué es el batching dinámico?

Agrupar peticiones que llegan en una ventana corta de tiempo en un solo lote para maximizar el uso de la GPU (throughput). El trade-off es latencia vs throughput: lotes más grandes mejoran la utilización pero añaden espera. Lo implementan motores como NVIDIA Triton y vLLM con continuous batching. Para latencia estricta se combina con particionado de la cola por SLA.

Q15. ¿Cómo se escala una solución RAG / base vectorial?

Con índices ANN eficientes (HNSW, IVF-PQ), sharding y réplicas de lectura, filtros por metadatos para reducir el espacio de búsqueda, re-ranking en dos etapas (recuperación amplia + reordenamiento preciso), caché de embeddings y actualización incremental del índice. A gran escala se separa el almacenamiento vectorial del motor de búsqueda y se evalúa calidad (recall/precision) en cada cambio.

Q16. ¿Cómo se diseña el escalado multi-región y alta disponibilidad?

Replicación de servicios y datos por región, failover automático, enrutamiento por latencia (CDN/global load balancing) y despliegues versionados del modelo consistentes en todas las regiones. Restricción clave de gobernanza: residencia de datos; hay que garantizar que los datos de entrenamiento e inferencia no crucen fronteras no permitidas y que el failover respete esas reglas.

Q17. ¿Autoscaling por CPU/GPU o por colas? ¿Y serverless?

Para cargas de IA, el autoscaling por CPU suele ser pobre; es mejor escalar por métricas relevantes: profundidad de cola (KEDA con SQS/Kafka), utilización de GPU, tokens pendientes o latencia objetivo. Serverless GPU (scale-to-zero) reduce costo en cargas intermitentes a cambio de cold starts; para latencia crítica se mantiene un mínimo de instancias calientes.

Q18. ¿Cómo se escalan los pipelines de datos para IA?

Con procesamiento distribuido (Spark), streaming donde el caso lo requiera (Kafka), orquestación (Airflow), particionado y formato columnar/lakehouse (Parquet, Delta, Iceberg), y validación automatizada de calidad de datos (Great Expectations) como gate antes de entrenar. Los feature pipelines se versionan junto con el código y el modelo para garantizar reproducibilidad.

Q19. ¿Qué métricas definen capacidad y rendimiento en IA?

Throughput (RPS, tokens/s), latencia p50/p95/p99, TTFT (time to first token) en LLM, tokens por segundo por usuario, utilización de GPU/memoria, error rate, saturación de colas y costo por inferencia / por 1.000 tokens. Se fijan SLOs por caso de uso y se capacita con pruebas de carga realistas (incluyendo prompts largos y concurrencia).

Q20. ¿Cuándo conviene edge/federado en lugar de centralizado?

Cuando hay latencia crítica (tiempo real industrial), conectividad limitada, o cuando la privacidad exige que los datos no salgan del dispositivo (salud, finanzas, sector público). El aprendizaje federado entrena modelos sin centralizar datos, a cambio de mayor complejidad operativa y de investigación. Es una decisión de arquitectura y de cumplimiento, no solo técnica.

Q21. ¿Qué es el gobierno de IA?

Es el conjunto de políticas, procesos, roles y controles con los que una organización dirige y supervisa el uso de la IA para alinearlo con su estrategia, la ley, los valores éticos y las expectativas de sus partes interesadas. El estándar ISO/IEC 38507:2022 describe las implicaciones de gobierno del uso de IA en las organizaciones y cómo integrarlas en los órganos de gobierno existentes (junta, comités, auditoría).

Q22. ¿Qué elementos mínimos tiene un programa de gobierno de IA?

• Política de IA aprobada por la dirección (usos permitidos/prohibidos).
• Comité de gobernanza de IA con roles y responsabilidades definidos.
• Inventario de casos de uso y clasificación por riesgo.
• Evaluaciones de riesgo e impacto por sistema, y controles por etapa del ciclo de vida.
• Formación y alfabetización en IA; gestión de incidentes; auditoría y métricas de cumplimiento.

Q23. ¿Qué es el inventario de sistemas de IA y por qué es clave?

Es el registro central de todos los sistemas y casos de uso de IA de la organización, con datos como: responsable (owner), propósito, datos utilizados, modelo/proveedor, clasificación de riesgo, estado de cumplimiento y controles aplicados. Es el punto de partida de cualquier marco de gobernanza: sin inventario no hay control, y es una de las primeras cosas que pide una auditoría (ISO/IEC 42001) o un regulador (EU AI Act, NIST AI RMF – función Map).

Q24. ¿Cómo se clasifican los sistemas de IA por riesgo?

Con un enfoque proporcional tipo EU AI Act: riesgo inaceptable (usos prohibidos: puntuación social, manipulación), alto riesgo (empleo, crédito, salud, educación, infraestructura crítica: obligaciones estrictas), riesgo limitado (obligaciones de transparencia, p. ej. chatbots o contenido generado) y riesgo mínimo (spam, videojuegos). ISO/IEC 42001 exige un enfoque equivalente: la evaluación de riesgo y de impacto determina qué controles del Anexo A aplican (declaración de aplicabilidad).

Q25. ¿Qué roles suelen existir en la gobernanza de IA?

Dirección/board (aprobación de política y apetito de riesgo), CAIO o Head of AI (estrategia), comité de gobernanza/ética de IA (decisión), AI Governance Officer / responsable de cumplimiento de IA, Model Risk Management (validación de modelos), DPO (privacidad), CISO (seguridad), dueños de caso de uso (owners), auditoría interna (aseguramiento). En organizaciones pequeñas los roles se combinan, pero las responsabilidades deben estar documentadas.

Q26. ¿Qué debe contener una política de IA?

Principios y compromisos (uso responsable, cumplimiento legal, ética), usos permitidos y prohibidos, proceso de aprobación de nuevos casos de uso, requisitos de datos, seguridad y privacidad, evaluación de riesgo/impacto obligatoria, transparencia con usuarios, roles y responsabilidades, formación, gestión de incidentes y consecuencias del incumplimiento. Es el documento de nivel 1 del sistema de gestión (cláusula 5.2 de ISO/IEC 42001).

Q27. ¿Cómo se relaciona el gobierno de IA con el gobierno de datos?

El gobierno de datos (calidad, linaje, propiedad, clasificación, consentimiento, retención) es la base del gobierno de IA: un modelo solo es confiable y auditable si sus datos lo son. Sin dueños de datos, linaje y controles de calidad no se puede demostrar cumplimiento ni gestionar riesgos como sesgo, fuga de información o uso indebido. En ISO/IEC 42001 el control de datos es un dominio completo del Anexo A (A.7).

Q28. ¿Cómo se gobierna específicamente la IA generativa?

Con política de uso aceptable de GenAI, catálogo de herramientas aprobadas (para frenar shadow AI), controles de datos (no pegar información confidencial en herramientas públicas, DLP), requisitos contractuales con proveedores (retención cero de datos, no entrenamiento con nuestros datos, indemnización), revisión de salidas en procesos críticos, marcas de contenido generado y formación a empleados.

Q29. ¿Qué es el «shadow AI» y cómo se gestiona?

Es el uso no autorizado de herramientas de IA por empleados (chatbots públicos, extensiones, scripts con APIs) sin pasar por seguridad o cumplimiento. Se gestiona con inventario y detección (CASB, DLP, análisis de tráfico), una alternativa corporativa aprobada que sea fácil de usar, políticas claras con consecuencias, y capacitación para que el equipo entienda los riesgos (fuga de datos, propiedad intelectual, cumplimiento).

Q30. ¿Cómo se demuestra cumplimiento ante un auditor o regulador?

Con evidencia documentada y trazable: política de IA, actas del comité, inventario de sistemas, evaluaciones de riesgo e impacto, declaración de aplicabilidad de controles, registros de formación, resultados de pruebas (sesgo, robustez, seguridad), informes de monitoreo, gestión de incidentes y auditorías internas. La trazabilidad a marcos (ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF) demuestra que el sistema de gestión funciona y mejora de forma continua.

Q31. ¿En qué se diferencia la seguridad de IA de la ciberseguridad tradicional?

Añade nuevas superficies de ataque: datos de entrenamiento, modelos, prompts, embeddings y la cadena de suministro de modelos. Aparecen amenazas propias (evasión adversarial, envenenamiento de datos, extracción de modelos, prompt injection) y el modelo se convierte en un componente más a proteger y monitorear. Además, la IA es a la vez herramienta de defensa y de ataque, lo que exige integrar seguridad de IA dentro del programa de ciberseguridad existente, no como un silo aparte.

Q32. ¿Qué es el prompt injection y cómo se mitiga?

Es una técnica donde un atacante inserta instrucciones maliciosas que el modelo obedece: directa (el usuario escribe instrucciones para eludir restricciones) o indirecta (instrucciones ocultas en documentos, páginas web o correos que el modelo lee vía RAG). Mitigaciones: separar instrucciones de datos, validar y sanitizar entradas y contenido recuperado, filtros de entrada/salida, mínimo privilegio para herramientas (que una inyección no pueda ejecutar acciones críticas), confirmación humana en acciones sensibles y monitoreo continuo.

Q33. ¿Qué es el envenenamiento de datos/modelos (poisoning)?

Manipular los datos de entrenamiento o ajuste para degradar el modelo o implantar comportamientos maliciosos (puertas traseras que se activan con un patrón concreto). Controles: procedencia verificada de datos, validación y limpieza, revisión de datasets de terceros, pruebas de integridad y de robustez, análisis de comportamiento anómalo tras desplegar y reentrenamientos con datos controlados.

Q34. ¿Qué es el OWASP Top 10 para aplicaciones LLM?

Es la lista de referencia de riesgos de seguridad en aplicaciones con LLM (versión 2025):

• LLM01 Prompt Injection — LLM02 Sensitive Information Disclosure — LLM03 Supply Chain
• LLM04 Data and Model Poisoning — LLM05 Improper Output Handling — LLM06 Excessive Agency
• LLM07 System Prompt Leakage — LLM08 Vector and Embedding Weaknesses — LLM09 Misinformation — LLM10 Unbounded Consumption

Q35. ¿Cuáles son los riesgos de la cadena de suministro de IA?

Modelos preentrenados comprometidos o sin procedencia verificada, datasets envenenados, dependencias y paquetes maliciosos, servicios y APIs de terceros, y plugins/herramientas inseguras. Controles: inventario de componentes (SBOM/AI-BOM), repositorios aprobados, verificación de hashes y firmas, escaneo de artefactos, evaluación de proveedores y contratos con requisitos de seguridad y transparencia.

Q36. ¿Cómo se protege un modelo frente al robo o la extracción?

Controlando el acceso a pesos y endpoints (autenticación, autorización, cuotas), limitando la información devuelta por las APIs (sin logits crudos ni detalles internos), detectando patrones de consulta anómalos (ataques de extracción masiva), aplicando marcas de agua cuando aplique, cifrando artefactos y usando entornos aislados (TEEs) para modelos críticos. El modelo es propiedad intelectual y a la vez un activo regulado.

Q37. ¿Qué es el red teaming de IA?

Es un ejercicio estructurado de ataque al sistema de IA (jailbreaks, fuga de datos, inyecciones, abusos de herramientas, sesgos explotables) realizado por equipos internos o externos antes del lanzamiento y de forma periódica. Combina técnicas automáticas (herramientas de escaneo) y manuales (expertos que piensan como atacantes). Los hallazgos se priorizan, remedian y documentan; es una práctica clave tanto de seguridad como de evaluación de riesgo y de cumplimiento (EU AI Act para modelos de propósito general requiere evaluaciones adversarias).

Q38. ¿Qué controles de seguridad aplicar a agentes de IA?

Mínimo privilegio en cada herramienta y credencial, sandboxing de ejecución, listas blancas de acciones, límites de recursos y gasto, confirmación humana para acciones sensibles o irreversibles (pagos, borrados, envíos), auditoría completa de decisiones y acciones del agente, separación de entornos y kill switch. El riesgo «Excessive Agency» (OWASP LLM06) es el más crítico: un agente con demasiados permisos convierte un error del modelo en un incidente real.

Q39. ¿Qué es MLSecOps y cómo se integra en CI/CD?

Es la extensión de DevSecOps al ciclo de vida de ML: escaneo de dependencias y artefactos, validación de datasets y modelos, pruebas de robustez y sesgo, gates de aprobación antes de desplegar, gestión de secretos, versionado seguro de modelos y monitoreo continuo en producción. Se integra en los pipelines de MLOps para que los controles de seguridad sean automáticos y no un paso manual que se omite bajo presión de entrega.

Q40. ¿Qué es el consumo ilimitado / DoS en sistemas de IA?

El abuso de recursos (prompts enormes, bucles de agentes, consultas masivas automatizadas) que agota presupuesto de tokens, GPU o cuotas, degradando el servicio o generando pérdidas económicas. Mitigaciones: rate limiting, cuotas por usuario y por token, límites de longitud y de iteraciones de agentes, timeouts, presupuestos por aplicación y alertas de anomalías de consumo (OWASP LLM10).

Q41. ¿Qué implicaciones tiene la IA para la privacidad?

Los datos de entrenamiento pueden contener información personal; los modelos pueden memorizar y regurgitar datos (especialmente LLM), permitir inferencias sobre individuos (membership inference, atributos sensibles), habilitar decisiones automatizadas con efectos legales y transferir datos a terceros/proveedores. Todo esto exige base legal, finalidad determinada, transparencia y controles técnicos, tanto en entrenamiento como en operación.

Q42. ¿Qué principios de privacidad aplicar?

Privacidad desde el diseño y por defecto, minimización de datos, limitación de la finalidad, exactitud, limitación del plazo de conservación, transparencia y consentimiento cuando corresponda. Referencias: GDPR art. 5 (principios), GDPR art. 22 (decisiones automatizadas) y, en Colombia, Ley 1581 de 2012 (Habeas Data) con su régimen de tratamiento de datos personales, aplicable también a sistemas de IA que traten datos de personas.

Q43. ¿Cómo se puede entrenar con datos sensibles de forma responsable?

Anonimización/pseudonimización robusta, agregación, privacidad diferencial (añadir ruido calibrado), aprendizaje federado (los datos no salen del origen), datos sintéticos generados con garantías, entornos seguros de análisis (data clean rooms) y acuerdos de tratamiento con los proveedores. La decisión se documenta en la evaluación de impacto y con aprobación del DPO.

Q44. ¿Qué es una DPIA/EIPD en proyectos de IA?

La Evaluación de Impacto relativa a la Protección de Datos es obligatoria (GDPR art. 35 y regulaciones equivalentes) cuando el tratamiento implica alto riesgo para los derechos de las personas: decisiones automatizadas con efecto significativo, perfilado, datos sensibles o vigilancia a gran escala. Documenta la necesidad y proporcionalidad del tratamiento, los riesgos identificados, las medidas mitigadoras y la opinión del DPO; en IA se complementa con la evaluación de impacto de sistemas de IA que exige ISO/IEC 42001.

Q45. ¿Qué dice el GDPR sobre las decisiones automatizadas?

El artículo 22 establece el derecho a no ser objeto de una decisión basada únicamente en tratamiento automatizado que produzca efectos jurídicos o significativos, salvo excepciones estrictas (necesidad contractual, ley, consentimiento explícito). En esos casos se garantiza intervención humana, derecho a expresar el punto de vista, a obtener explicación y a impugnar la decisión. Es directamente aplicable a sistemas de IA que deciden sobre créditos, empleo, seguros, etc.

Q46. ¿Qué es la retención cero (zero data retention) con proveedores de IA?

Es una cláusula contractual por la cual el proveedor de servicios de IA no almacena los prompts ni las respuestas del cliente, no los usa para entrenar sus modelos y no los comparte; idealmente tampoco los procesa en subencargados sin control. Es una condición práctica para poder usar IA de terceros con datos corporativos, y debe revisarse junto con las ubicaciones de procesamiento (transferencias internacionales) y los planes de respuesta ante incidentes del proveedor.

Q47. ¿Cuáles son los riesgos de fuga de información en RAG?

El recuperador puede devolver documentos a los que el usuario no tiene permiso (el índice vectorial no hereda automáticamente los permisos del origen). Controles: indexar con metadatos de control de acceso y filtrar por permisos en tiempo de consulta, sincronizar los cambios de permisos del sistema origen, evaluar el grounding y auditar consultas. Es un riesgo de privacidad y de seguridad a la vez (OWASP LLM08: debilidades en vectores y embeddings).

Q48. ¿Cómo se anonimiza de forma efectiva en la era de la IA?

«Quitar los nombres» no es suficiente: con datos ricos, la reidentificación es viable. Se combinan técnicas: k-anonimato y l-diversidad para agregación, privacidad diferencial para consultas y entrenamiento, generalización y supresión de cuasi-identificadores, y evaluación formal del riesgo de reidentificación antes de publicar o compartir. La anonimización se valida con pruebas, no con una declaración.

Q49. ¿Qué marcos existen para la gestión de riesgos de IA?

• ISO/IEC 23894:2023: guía de gestión de riesgos de IA, basada en ISO 31000, con catálogo de fuentes de riesgo de IA.
• NIST AI RMF 1.0: marco voluntario con cuatro funciones: Govern, Map, Measure, Manage (y el perfil de IA generativa NIST AI 600-1).
• ISO/IEC 42001:2023: sistema de gestión certificable que integra riesgo + impacto de IA.
• EU AI Act: cumplimiento regulatorio obligatorio por nivel de riesgo.
• FAIR: enfoque cuantitativo para priorizar pérdidas por escenarios de riesgo.

Q50. ¿Cómo es el proceso de gestión de riesgos (ciclo completo)?

1) Identificar riesgos y fuentes (usar catálogos como ISO/IEC 23894 y las experiencias del sector); 2) analizar y evaluar probabilidad e impacto frente al apetito de riesgo; 3) tratar (mitigar, evitar, transferir, aceptar) definiendo controles y responsables; 4) monitorear y revisar de forma continua; 5) registrar y comunicar en el registro de riesgos con dueños, plazos y evidencia. Es un ciclo vivo, no un documento anual.

Q51. ¿Cuáles son los riesgos típicos de un sistema de IA?

Sesgo y discriminación (datos o modelo), alucinación e incorrección, drift de datos y de concepto, fallos de seguridad (prompt injection, fuga de datos), privacidad (memorización, inferencias), incumplimiento regulatorio, dependencia de proveedores, costos descontrolados por consumo, reputación y confianza, impacto ambiental por consumo de cómputo, y uso indebido por usuarios o partes internas.

Q52. ¿Qué es el apetito de riesgo aplicado a IA?

Es el nivel de riesgo que la organización está dispuesta a asumir por tipo de caso de uso. Se expresa en una matriz de tolerancia (por ejemplo: riesgo bajo aceptable en asistentes internos; riesgo mínimo para decisiones legales, salud o crédito) y guía la clasificación de los sistemas y la proporcionalidad de los controles. La dirección lo aprueba y se revisa periódicamente (cláusula 6 de ISO/IEC 42001).

Q53. ¿Cómo se monitorea el riesgo de un modelo en producción?

Con monitoreo de drift (distribución de entrada y relación datos-resultado), degradación de métricas de negocio y de modelo, análisis de sesgo por subgrupos, alertas por umbrales, revisión periódica del registro de riesgos y disparadores de reentrenamiento o retiro del modelo. Los incidentes alimentan el ciclo de aprendizaje: cada fallo actualiza evaluaciones y controles.

Q54. ¿Qué es la evaluación de impacto de sistemas de IA?

Es un requisito distintivo de ISO/IEC 42001 (cláusula 6.1.4): analizar cómo el sistema afecta a individuos, grupos vulnerables, sociedad y medio ambiente, más allá del riesgo para la organización. Su resultado condiciona si el caso de uso es aceptable y qué controles adicionales requiere (transparencia, supervisión humana, restricciones). Se complementa con la guía ISO/IEC 42005 y, en privacidad, con la DPIA.

Q55. ¿Cómo se gestiona el riesgo de terceros (proveedores y modelos)?

Con due diligence previa (seguridad, privacidad, cumplimiento, estabilidad), contratos que fijen responsabilidades (indemnización, notificación de incidentes, retención cero, uso de datos), gestión de cambios de versión del modelo (aviso previo y evaluación del impacto), monitoreo continuo del desempeño y planes de salida (evitar lock-in: portabilidad de prompts, datos y arquitectura).

Q56. ¿Cómo se maneja un incidente de IA?

Igual que un incidente de seguridad, con pasos adicionales: detección (monitoreo, reportes de usuarios), contención (desactivar el caso de uso, degradar a modo humano, rollback del modelo), análisis de causa raíz (datos, modelo, prompt, integración), notificación (regulador y afectados si corresponde por ley), remediación y lecciones aprendidas que actualizan riesgos y controles. Debe existir un procedimiento documentado y probado; el regulador evalúa cómo la organización detectó y respondió.

Q57. ¿Qué significa uso responsable de IA?

Desarrollar y usar IA de forma alineada con los derechos humanos, los valores éticos y la ley, gestionando activamente sus impactos en las personas y la sociedad. Se concreta en seis pilares clásicos: equidad, confiabilidad y seguridad, privacidad y seguridad de la información, inclusividad, transparencia y responsabilidad (accountability). No es solo ética declarativa: se implementa con procesos, controles y evidencia auditable.

Q58. ¿Cuáles son los seis pilares en detalle?

• Equidad: tratar a todas las personas de forma justa, evitando sesgos y discriminación.
• Confiabilidad y seguridad: el sistema funciona de forma consistente y sin causar daño.
• Privacidad y seguridad de la información: proteger datos personales y corporativos.
• Inclusividad: diseño accesible y que beneficie a todos los grupos, incluyendo vulnerables.
• Transparencia: explicar capacidades, límites y cómo funcionan las decisiones.
• Responsabilidad: personas y procesos que rinden cuentas por los resultados del sistema.

Q59. ¿Qué es la equidad (fairness) y cómo se evalúa?

Es la ausencia de sesgos injustificados contra grupos protegidos. Se evalúa midiendo métricas por subgrupos (paridad demográfica, igualdad de oportunidades, tasa de falsos positivos/negativos), analizando datos históricos y variables proxy, y probando escenarios contrafactuales. Las mitigaciones se aplican antes (recolección y balanceo), durante (función de pérdida, restricciones) o después del modelo (ajuste de umbrales), con participación de stakeholders afectados.

Q60. ¿Qué son explicabilidad e interpretabilidad?

La interpretabilidad describe por qué el modelo produce una salida (técnicas: SHAP, LIME, importancia de variables, contrafactuales, mapas de atención); la explicabilidad es la capacidad de comunicar esa razón en términos comprensibles para la persona afectada y para el negocio. En decisiones de alto impacto hay derecho a explicación; en LLM se refuerza con citas de fuentes, resúmenes de razonamiento y evaluaciones de fidelidad. Todo modelo desplegado debería tener su modelo documentado (model card): propósito, datos, métricas, limitaciones.

Q61. ¿Qué es la supervisión humana (human-in-the-loop)?

Es el diseño explícito de puntos donde las personas revisan, aprueban o pueden revertir decisiones del sistema: human-in-the-loop (aprobación antes de actuar), human-on-the-loop (supervisión con capacidad de intervenir) y human-in-command (control estratégico y capacidad de desconectar). Obligatorio en decisiones de alto impacto; requiere interfaces claras, información suficiente para decidir y conciencia del sesgo de automatización (no aprobar por inercia).

Q62. ¿Qué son la transparencia y la rendición de cuentas en IA?

Transparencia: comunicar de forma clara qué hace el sistema, qué datos usa, cuáles son sus límites, cuándo el usuario interactúa con IA o consume contenido generado (system cards, avisos). Rendición de cuentas: responsables definidos por sistema, trazabilidad de decisiones, canales de apelación y reclamación para afectados, y reporte de incidentes e indicadores de cumplimiento a la dirección y al público según corresponda.

Q63. ¿Qué principios internacionales enmarcan el uso responsable?

Los Principios de IA de la OCDE (2019, actualizados en 2024), la Recomendación de la UNESCO sobre la Ética de la IA (2021), los Principios Rectores de la ONU sobre Empresas y Derechos Humanos (2011) y las declaraciones del G20. Todos convergen en: beneficio para las personas y el planeta, no causar daño, proporcionalidad, transparencia y explicabilidad, seguridad y robustez, y responsabilidad. Estos principios alimentan leyes nacionales y marcos como ISO/IEC 42001.

Q64. ¿Qué es la alfabetización en IA (AI literacy) y por qué importa?

Es la formación de empleados y usuarios para entender capacidades, límites y riesgos de la IA, y usarla de forma crítica y segura. Es una buena práctica de todo programa de gobernanza y una obligación regulatoria: el EU AI Act exige medidas de alfabetización en IA a los proveedores y usuarios de sistemas de IA. ISO/IEC 42001 la cubre en la cláusula 7.2 (competencia) y el control A.4.4.

Q65. ¿Qué es ISO/IEC 42001:2023?

Es el primer estándar internacional, certificable, que especifica los requisitos para establecer, implementar, mantener y mejorar un sistema de gestión de inteligencia artificial (AIMS). Publicado en diciembre de 2023 por ISO/IEC. Aplica a cualquier organización que desarrolle, provea o utilice productos y servicios de IA, y da una base común para demostrar uso responsable y cumplimiento frente a clientes, reguladores y socios.

Q66. ¿Cuál es la estructura de la norma?

Sigue la estructura armonizada de sistemas de gestión (igual que ISO/IEC 27001): cláusulas 4 a 10 (contexto, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora) y anexos de apoyo: Anexo A (objetivos de control y controles), Anexo B (guía de implementación de los controles), Anexo C (fuentes y objetivos de riesgo de IA) y Anexo D (cómo aplicar la norma en distintos dominios y sectores).

Q67. ¿Qué exigen las cláusulas 4 y 5?

Cláusula 4 – Contexto: entender la organización y sus partes interesadas, sus requisitos y expectativas, y definir el alcance del AIMS. Cláusula 5 – Liderazgo: la alta dirección debe aprobar una política de IA, asignar roles y responsabilidades y asegurar que la gestión de IA se integre en los procesos de negocio. Sin liderazgo visible no hay sistema de gestión eficaz.

Q68. ¿Qué exige la cláusula 6 y qué la hace distintiva?

La planificación incluye el doble enfoque que distingue a 42001: evaluación de riesgos de IA (6.1.2) y su tratamiento (6.1.3) — como en 27001 — más una evaluación de impacto de sistemas de IA (6.1.4) orientada a personas, grupos vulnerables, sociedad y ambiente. También fija objetivos de IA medibles (6.2). El impacto condiciona la aceptación del sistema y los controles proporcionales.

Q69. ¿Qué exigen las cláusulas 7 y 8?

Cláusula 7 – Soporte: recursos, competencia y alfabetización en IA, sensibilización, comunicación e información documentada (la evidencia del sistema). Cláusula 8 – Operación: ejecutar lo planificado mediante los controles del ciclo de vida (diseño, datos, desarrollo, despliegue, retiro), gestión de terceros, uso responsable del sistema y tratamiento de incidentes y reportes.

Q70. ¿Qué exigen las cláusulas 9 y 10?

Cláusula 9 – Evaluación del desempeño: seguimiento y medición, auditoría interna y revisión por la dirección, con indicadores del AIMS y del cumplimiento de objetivos. Cláusula 10 – Mejora: gestión de no conformidades y acciones correctivas, y mejora continua del sistema. Es el ciclo PDCA clásico de todo estándar de gestión, aplicado a la IA.

Q71. ¿Qué es el Anexo A y cómo se usa?

Es el catálogo de 38 controles organizados en 9 dominios (A.2 a A.10):

• A.2 Políticas relacionadas con IA — A.3 Organización interna
• A.4 Recursos para sistemas de IA — A.5 Evaluación de impactos de sistemas de IA
• A.6 Ciclo de vida del sistema de IA — A.7 Datos para sistemas de IA
• A.8 Información para interesados — A.9 Uso de sistemas de IA — A.10 Relaciones con terceros y clientes

Q72. ¿Cómo se certifica una organización en ISO/IEC 42001?

Con una auditoría de tercera parte por un organismo acreditado: análisis de brechas, implementación del AIMS, auditoría interna, y proceso de certificación en dos fases (revisión documental y auditoría en sitio). El certificado tiene vigencia de 3 años con auditorías de seguimiento anuales. Puede integrarse con ISO/IEC 27001 en un sistema de gestión integrado, compartiendo estructura, riesgos, auditorías y gobierno.

Q73. ¿Cuál es la relación con ISO/IEC 27001 (seguridad de la información)?

Ambas siguen la estructura armonizada y se diseñan para integrarse. 27001 protege la información (confidencialidad, integridad, disponibilidad) y 42001 gobierna la IA con foco en impacto y uso responsable. Comparten prácticas (políticas, gestión de riesgos, auditoría, competencia) y muchos controles de seguridad de la información son prerrequisito para un AIMS sólido: una organización con 27001 maduro tiene un camino más corto hacia 42001 y viceversa.

Q74. ¿Qué otros estándares complementan a 42001?

• ISO/IEC 22989: conceptos y terminología de IA (vocabulario común).
• ISO/IEC 23053: framework de sistemas de IA basados en machine learning.
• ISO/IEC 23894: guía de gestión de riesgos de IA (alimenta la cláusula 6).
• ISO/IEC 38507: implicaciones de gobierno del uso de IA.
• ISO/IEC 5338: procesos del ciclo de vida de sistemas de IA.
• ISO/IEC 25059, TR 24027 y TR 24028: calidad de sistemas de IA, sesgo y confiabilidad.
• ISO/IEC 42005 y 42006: guía de evaluación de impacto y requisitos para organismos de certificación.

Q75. ¿Cuáles son los pasos prácticos para implementar ISO/IEC 42001?

1. Compromiso de la dirección y definición del alcance del AIMS.
2. Análisis de brechas frente a los requisitos de la norma.
3. Política de IA, roles y comité de gobernanza.
4. Inventario de sistemas de IA y evaluaciones de riesgo e impacto.
5. Plan de tratamiento y controles del Anexo A con Declaración de Aplicabilidad.
6. Competencia, formación y control de la documentación (cláusulas 7).
7. Operación, monitoreo y medición (cláusulas 8 y 9).
8. Auditoría interna, revisión por la dirección y plan de mejora.
9. Auditoría de certificación por organismo acreditado.

Q76. ¿Qué beneficios aporta 42001 a una organización?

Gobernanza de IA estructurada y demostrable, confianza de clientes, socios y reguladores, ventaja en licitaciones que exigen IA responsable, alineación anticipada con regulaciones (EU AI Act y normas locales), gestión sistemática de riesgos e impactos, mejor calidad de los sistemas por el ciclo de mejora continua, y una base común de lenguaje y controles para todos los equipos que usan IA.

Q77. ¿A quién aplica la norma y qué evidencia se revisa en auditoría?

A organizaciones de cualquier tamaño y sector que desarrollen, provean o usen IA (incluye a quien la consume como servicio). Evidencia típica: política de IA, alcance y contexto, registro de riesgos e impactos, inventario de sistemas, declaración de aplicabilidad, registros de competencia y formación, contratos y evaluaciones de terceros, resultados de monitoreo, gestión de incidentes, informes de auditoría interna y actas de revisión por la dirección.

Q78. ¿Cómo se relacionan ISO/IEC 42001, NIST AI RMF y el EU AI Act?

• ISO/IEC 42001: estándar de requisitos certificable de sistema de gestión de IA (qué hay que tener y demostrar).
• NIST AI RMF: marco voluntario orientador (Govern, Map, Measure, Manage) muy útil para operar el ciclo de riesgo; no certificable, complementario.
• EU AI Act: regulación obligatoria por nivel de riesgo; para sistemas de alto riesgo exige un sistema de gestión de calidad que un AIMS basado en 42001 ayuda a cumplir, junto con documentación técnica, supervisión humana y evaluaciones.