Cybersecurity 18 — AI-GRC & Security Governance

1. Objetivos de aprendizaje

Al finalizar este módulo el alumno deberá ser capaz de diseñar un sistema de gobierno de IA que conecte las decisiones estratégicas con los controles técnicos implementados en infraestructura, aplicaciones, modelos, datos, CI/CD y SOC.

Competencias

Diseñar un AI Governance Framework.
Crear un inventario corporativo de sistemas de IA.
Clasificar sistemas según riesgo.
Construir un AI Risk Register.
Definir AI Security Policies.
Mapear riesgos con controles.
Diseñar un proceso de aprobación de modelos.
Gestionar proveedores de IA.
Evaluar terceros.
Gestionar excepciones.
Definir evidencias de control.
Diseñar métricas y KRIs.
Integrar GRC con SOC.
Gestionar incidentes de IA.
Gestionar el ciclo de vida completo.
Preparar auditorías.
Mapear marcos NIST, ISO y OWASP.
Comprender las implicaciones del EU AI Act.
Diseñar un programa corporativo de AI Security.

2. ¿Qué es AI Governance?

AI Governance es el conjunto de estructuras, responsabilidades, políticas, procesos y controles mediante los cuales una organización decide cómo puede utilizarse la Inteligencia Artificial.

No es únicamente Compliance

                 AI GOVERNANCE
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
      RISK          SECURITY       COMPLIANCE
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                 OPERATIONS
                       │
                       ▼
                     AI

Un programa maduro debe conectar gobierno y tecnología.

3. Modelo operativo de AI Security

La organización debe definir quién es responsable de cada decisión.

Rol	Responsabilidad
Board / Dirección	Risk appetite y supervisión.
CISO	Seguridad y riesgo tecnológico.
AI Governance	Políticas y gobierno de IA.
Data Owner	Gobierno de los datos.
Model Owner	Responsabilidad sobre el modelo.
AI Engineering	Implementación técnica.
SOC	Detección y respuesta.
Legal / Compliance	Requisitos regulatorios y contractuales.
Risk	Evaluación y tratamiento del riesgo.

RACI

Actividad                  R     A     C     I

AI Inventory              AI    CISO  Legal  Board
Risk Assessment           Risk  CISO  AI     Board
Model Approval            AI    CISO  Data   Legal
Security Testing          Sec   CISO  AI     Risk
Production Deployment     Dev   AI    Sec    Risk
Incident Response         SOC   CISO  AI     Legal
Vendor Assessment         Risk  CISO  Legal  AI

4. AI Asset Inventory

No puede gobernarse lo que no conocemos.

La primera capacidad de un programa de AI Governance debe ser conocer todos los sistemas de IA existentes en la organización.

Inventario mínimo

Campo	Ejemplo
AI System ID	AI-CRM-001
Business Owner	Sales
Technical Owner	AI Platform
Purpose	Customer support
Model	Internal LLM v7
Data	Customer conversations
Provider	Internal / External
Risk Level	High
Environment	Production
Security Status	Approved
Last Assessment	2026-08-01

5. AI Risk Classification

No todos los sistemas de IA tienen el mismo riesgo.

Ejemplo de clasificación corporativa

LOW

Productividad interna sin datos sensibles ni decisiones críticas.

MEDIUM

Sistemas que procesan información corporativa o automatizan procesos.

HIGH

Sistemas con impacto significativo sobre personas, operaciones o seguridad.

CRITICAL

IA integrada en procesos críticos o infraestructuras esenciales.

Modelo de scoring

Risk Score =
    Impact
  × Likelihood
  × Exposure
  × Autonomy
  × Data Sensitivity

El objetivo no es conseguir una fórmula perfecta. El objetivo es disponer de un mecanismo consistente para priorizar.

6. AI Risk Management

Ciclo de gestión

IDENTIFY
   │
   ▼
ASSESS
   │
   ▼
TREAT
   │
   ▼
CONTROL
   │
   ▼
MONITOR
   │
   ▼
REVIEW
   │
   └───────────────► IDENTIFY

Tratamiento del riesgo

Estrategia	Ejemplo
Avoid	No utilizar IA para determinado proceso.
Reduce	Aplicar controles técnicos.
Transfer	Contrato y garantías con proveedor.
Accept	Aceptación formal del riesgo residual.

7. AI Risk Register

El Risk Register debe convertirse en un elemento operativo, no en una hoja de cálculo olvidada.

ID	Riesgo	Likelihood	Impact	Score	Control	Owner
AI-R-001	Model poisoning	3	5	15	Model verification	AI Security
AI-R-002	Data leakage	4	5	20	DLP + access control	CISO
AI-R-003	Provider outage	3	4	12	Fallback provider	Platform

8. Risk Appetite para IA

La organización debe decidir qué riesgos está dispuesta a aceptar.

Ejemplo

CRITICAL:
    No unmanaged risk accepted.

HIGH:
    Requires CISO approval.

MEDIUM:
    Business owner + security approval.

LOW:
    Standard controls.

Principio importante:

No todos los riesgos pueden eliminarse. La responsabilidad del gobierno es hacerlos visibles, cuantificarlos y establecer quién acepta el riesgo residual.

9. AI Security Policies

Una política debe convertirse posteriormente en controles verificables.

Ejemplo

POLICY: AI-MODEL-001

All production models MUST:

1. Have an owner.
2. Have a version.
3. Have a SHA-256 hash.
4. Have provenance.
5. Be security tested.
6. Be registered.
7. Be approved.
8. Be signed.
9. Be monitored.
10. Have a rollback procedure.

De política a control

POLICY
  ↓
CONTROL
  ↓
IMPLEMENTATION
  ↓
EVIDENCE
  ↓
AUDIT

10. Control Framework

Los controles deben cubrir todo el ciclo de vida.

Dominio	Control
Governance	AI Inventory
Identity	Least Privilege
Data	Data Classification
Model	Model Verification
Supply Chain	SBOM / AI-BOM
Infrastructure	Container Security
Application	Secure Development
Operations	Monitoring
Incident	AI Incident Response
Third Party	Vendor Risk
Compliance	Evidence Management

11. NIST AI Risk Management Framework

El NIST AI RMF proporciona una estructura útil para organizar el gobierno del riesgo de IA.

Modelo conceptual

GOVERN
   │
   ├──────────────┐
   ▼              │
MAP              │
   │              │
   ▼              │
MEASURE          │
   │              │
   ▼              │
MANAGE ◄──────────┘

El alumno debe aprender a utilizar el framework como estructura de gestión, no como una simple lista de requisitos.

12. ISO/IEC 42001 e ISO 27001

ISO/IEC 42001 se orienta al sistema de gestión de IA, mientras que ISO/IEC 27001 proporciona un marco para el sistema de gestión de seguridad de la información.

Complementariedad

ORGANIZATION │ ┌───────────┴───────────┐ │ │ ISMS AI-MS ISO 27001 ISO 42001 │ │ └───────────┬───────────┘ ▼ AI SECURITY ```

Una organización madura debe evitar crear dos mundos completamente separados.

13. EU AI Act

El alumno debe comprender el enfoque basado en riesgo utilizado por la regulación europea de IA y, sobre todo, cómo traducir requisitos legales a controles técnicos y evidencias.

Principio

LEGAL REQUIREMENT
        │
        ▼
    RISK DOMAIN
        │
        ▼
 SECURITY CONTROL
        │
        ▼
 TECHNICAL IMPLEMENTATION
        │
        ▼
      EVIDENCE
        │
        ▼
       AUDIT

La clasificación regulatoria concreta depende del caso de uso, del rol de la organización, del sistema y de las obligaciones aplicables. Nunca debe reducirse el análisis a una simple etiqueta "IA = alto riesgo".

15. AI Vendor Risk Management

Un proveedor externo de IA debe formar parte del modelo de riesgo corporativo.

Vendor assessment

Dominio	Preguntas
Security	¿Qué controles técnicos aplica?
Privacy	¿Cómo utiliza nuestros datos?
Resilience	¿Cuál es su estrategia de continuidad?
Supply Chain	¿Cómo controla sus dependencias?
AI Governance	¿Cómo gobierna sus modelos?
Incident Response	¿Cómo comunica incidentes?
Exit	¿Podemos abandonar el servicio?

16. Third-Party AI Assurance

No basta con preguntar al proveedor si "es seguro".

Hay que solicitar evidencias.

Ejemplos

Certificaciones.
Auditorías.
Penetration tests.
Security whitepapers.
Architecture diagrams.
Data processing information.
Incident procedures.
Subprocessor information.
Business continuity.
Vulnerability management.

17. AI Approval Process

Ningún sistema de IA crítico debería llegar directamente a producción.

REQUEST
   │
   ▼
AI INVENTORY
   │
   ▼
RISK CLASSIFICATION
   │
   ▼
SECURITY ASSESSMENT
   │
   ▼
PRIVACY ASSESSMENT
   │
   ▼
LEGAL ASSESSMENT
   │
   ▼
TECHNICAL VALIDATION
   │
   ▼
APPROVAL
   │
   ▼
PRODUCTION
   │
   ▼
CONTINUOUS MONITORING

18. Exception Management

Las políticas no siempre pueden cumplirse inmediatamente.

Pero una excepción no debe significar simplemente "hacerlo igualmente".

Una excepción debería incluir

Control incumplido.
Justificación.
Riesgo asociado.
Compensating controls.
Owner.
Fecha de expiración.
Aprobador.
Plan de remediación.

EXCEPTION
   │
   ├── Risk
   ├── Owner
   ├── Approval
   ├── Compensating Controls
   └── Expiration Date

19. Evidence Management

Un control que no puede demostrarse es difícil de defender durante una auditoría.

Ejemplos de evidencias

Control	Evidence
Model Approval	Approval record
Model Integrity	Hash + signature
Dependency Security	Scan report
Container Security	Trivy report
Access Control	IAM logs
Monitoring	SOC dashboard
Incident Response	Incident record

20. Continuous Compliance

La seguridad de IA no debe depender de una auditoría anual.

CONTROL
   │
   ▼
AUTOMATION
   │
   ▼
EVIDENCE
   │
   ▼
CONTINUOUS MONITORING
   │
   ▼
ALERT
   │
   ▼
REMEDIATION

Este concepto conecta GRC con DevSecOps y SecOps.

21. AI Security Metrics

KPIs

Métrica	Objetivo
% AI systems inventoried	100%
% production models approved	100%
% models signed	100%
% critical vulnerabilities remediated	> 95%
% vendors assessed	100%
Mean remediation time	Reducir progresivamente

KRIs

Modelos sin owner.
Modelos sin provenance.
Artefactos sin firma.
Dependencias críticas.
Excepciones vencidas.
Sistemas fuera del inventario.
Uso de proveedores no aprobados.

22. AI Security Dashboard

┌──────────────────────────────────────────────┐
│             AI SECURITY COMMAND CENTER       │
├────────────┬────────────┬────────────────────┤
│ AI Assets  │ High Risk  │ Open Incidents     │
│    247     │     31     │        4           │
├────────────┴────────────┴────────────────────┤
│                                              │
│  Governance Coverage          94%             │
│  Model Approval               98%             │
│  Signed Models                96%             │
│  AI-BOM Coverage              91%             │
│  Vendor Assessment            87%             │
│                                              │
├──────────────────────────────────────────────┤
│ TOP RISKS                                    │
│ 1. Unapproved Model                          │
│ 2. Data Leakage                               │
│ 3. Supply Chain Vulnerability                 │
│ 4. Provider Dependency                        │
└──────────────────────────────────────────────┘

23. Integración entre GRC y AI-SOC

Uno de los objetivos más importantes del curso es conectar gobierno y operaciones.

                 AI-GRC
                   │
             Risk Register
                   │
                   ▼
              Security Controls
                   │
                   ▼
                 AI-SOC
                   │
             ┌─────┴─────┐
             ▼           ▼
          Detection    Incident
             │           │
             └─────┬─────┘
                   ▼
                Evidence
                   │
                   ▼
                 GRC
                   │
                   ▼
              Risk Update

Un incidente real debe modificar nuestra visión del riesgo.

24. AI Incident Governance

Ejemplo

El SOC detecta que un modelo utilizado en producción ha sido modificado fuera del pipeline autorizado.

Proceso

Detectar.
Clasificar.
Contener.
Preservar evidencias.
Investigar.
Determinar impacto.
Notificar cuando corresponda.
Recuperar.
Revisar controles.
Actualizar Risk Register.
Implementar acciones correctivas.

25. AI Lifecycle Governance

IDEA
 │
 ▼
DESIGN
 │
 ▼
DATA
 │
 ▼
TRAIN
 │
 ▼
TEST
 │
 ▼
APPROVE
 │
 ▼
DEPLOY
 │
 ▼
OPERATE
 │
 ▼
MONITOR
 │
 ▼
RETRAIN
 │
 ▼
RETIRE

La seguridad debe acompañar todas las etapas.

26. Model Retirement

Un modelo antiguo también representa un riesgo.

Checklist de retirada

Bloquear nuevos deployments.
Eliminar endpoints.
Revocar credenciales.
Retirar artefactos.
Preservar evidencias necesarias.
Actualizar inventario.
Actualizar AI-BOM.
Eliminar accesos.
Revisar dependencias.
Registrar fecha de retirada.

27. Mapping entre frameworks

Necesidad	NIST	ISO	OWASP	Control técnico
AI Risk	AI RMF	42001	LLM Risk	Risk Register
Security	CSF	27001	LLM Security	Security Controls
Supply Chain	SSDF	27001	SCVS	SBOM / Signatures
Incident	CSF	27001	—	AI-SOC

28. Laboratorio 1 — Crear un AI Risk Register

Escenario

Una empresa utiliza un agente de IA conectado a:

CRM.
ERP.
Base documental.
Internet.
Proveedor LLM externo.

El agente puede ejecutar acciones sobre el CRM.

Objetivo

Identificar al menos diez riesgos y priorizarlos.

Resolución orientativa

Riesgo	Impacto	Prob.	Prioridad
Prompt Injection	4	4	16
Excessive Agency	5	4	20
Data Leakage	5	4	20
Provider compromise	5	2	10
Credential theft	5	3	15

La mayor prioridad debería darse a los riesgos que combinan alto impacto con elevada probabilidad o exposición.

29. Laboratorio 2 — Diseñar una política corporativa de IA

Objetivo

Crear una política de diez reglas que regule el uso de IA en una organización.

Debe cubrir:

modelos;
datos;
proveedores;
usuarios;
desarrollo;
producción;
incidentes.

Ejemplo de estructura

AI-POL-001

1. Every AI system must have an owner.
2. Production AI must be inventoried.
3. High-risk AI requires security assessment.
4. Sensitive data requires explicit approval.
5. External providers require vendor assessment.
6. Production models require provenance.
7. Critical artifacts require signatures.
8. AI systems must be monitored.
9. Incidents must be reported.
10. Exceptions require documented approval.

30. Laboratorio 3 — Diseñar un control auditable

Situación

La política corporativa establece:

"All production AI models must be approved."

Pregunta

¿Cómo convertir esta frase en un control realmente auditable?

Resolución

CONTROL ID:
AI-MOD-001

OBJECTIVE:
Ensure only approved models reach production.

CONTROL:
Production deployment requires approval.

IMPLEMENTATION:
CI/CD approval gate.

EVIDENCE:
Approval record + deployment log.

OWNER:
AI Security.

FREQUENCY:
Continuous.

TEST:
Compare production model ID
against approved registry.

FAILURE:
Deployment blocked.

Esta transformación convierte una política abstracta en un control objetivamente comprobable.

31. Laboratorio 4 — Auditoría de un sistema de IA

Escenario

Se entrega el siguiente sistema:

LLM
 │
 ├── Vector DB
 ├── CRM
 ├── Web Search
 └── External API

Deployment:
Kubernetes

CI/CD:
GitHub Actions

El alumno debe determinar qué evidencias solicitaría antes de aprobar el sistema.

Resolución

AI inventory record.
Architecture diagram.
Threat model.
Risk assessment.
Data classification.
Model provenance.
SBOM.
AI-BOM.
Container scan.
Dependency scan.
IAM configuration.
Network policies.
Secrets management.
CI/CD controls.
Security testing.
Incident response plan.
Vendor assessment.
Approval record.

32. Laboratorio 5 — Diseñar un AI Security Governance Dashboard

Objetivo

Diseñar un dashboard para el CISO que permita conocer el estado global de la seguridad de IA.

Debe incluir:

número de sistemas;
nivel de riesgo;
modelos aprobados;
modelos sin firma;
vulnerabilidades;
excepciones;
proveedores;
incidentes;
cobertura AI-BOM;
cumplimiento.

33. Proyecto final — Enterprise AI Security Governance

Objetivo

Diseñar un programa completo de gobierno y seguridad de IA para una organización de tamaño empresarial.

El proyecto debe incluir

AI Governance Framework.
AI Inventory.
Risk Classification.
Risk Register.
AI Security Policies.
Control Framework.
Model Approval Process.
Third-Party Risk Management.
AI Supply Chain Controls.
SBOM / AI-BOM.
CI/CD Security Gates.
AI-SOC integration.
Incident Response.
Evidence Management.
Metrics and KRIs.
Exception Management.
Model Retirement.
Audit Strategy.
Framework Mapping.
Executive Dashboard.

Arquitectura final

                         BOARD
                           │
                           ▼
                    AI GOVERNANCE
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
        RISK           COMPLIANCE        SECURITY
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                    CONTROL FRAMEWORK
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
      GRC                 AI-SOC          AI PLATFORM
        │                  │                  │
        │                  │          ┌───────┼───────┐
        │                  │          ▼       ▼       ▼
        │                  │       Models    Data   Agents
        │                  │          │       │       │
        └──────────────────┼──────────┴───────┴───────┘
                           │
                           ▼
                    CONTINUOUS ASSURANCE
                           │
                           ▼
                        EVIDENCE
                           │
                           ▼
                         AUDIT
                           │
                           ▼
                    RISK IMPROVEMENT

34. Evaluación final

Área	Peso
AI Governance	10%
Risk Management	15%
Policies & Controls	10%
Compliance Frameworks	10%
Vendor Risk	10%
Evidence & Audit	10%
AI-SOC Integration	10%
Metrics & Dashboard	5%
Final Project	20%

35. Checklist profesional

☐ Existe AI Governance Framework.
☐ Todos los sistemas de IA están inventariados.
☐ Todos tienen un owner.
☐ Existe clasificación de riesgo.
☐ Existe AI Risk Register.
☐ Existe AI Security Policy.
☐ Las políticas se traducen en controles.
☐ Los controles tienen evidencias.
☐ Existe proceso formal de aprobación.
☐ Los modelos están versionados.
☐ Los modelos críticos están firmados.
☐ Existe AI-BOM.
☐ Se evalúan proveedores.
☐ Se gestionan excepciones.
☐ Las excepciones tienen fecha de expiración.
☐ Existe AI-SOC.
☐ Los incidentes actualizan el Risk Register.
☐ Existen métricas.
☐ Existen KRIs.
☐ Existe evidencia de cumplimiento.
☐ Existe estrategia de auditoría.
☐ Existe procedimiento de retirada de modelos.
☐ El gobierno es continuo.

36. Recursos y referencias

NIST

NIST AI Risk Management Framework (AI RMF)
NIST Cybersecurity Framework
NIST Secure Software Development Framework

ISO

ISO/IEC 27001 — Information Security Management Systems
ISO/IEC 42001 — Artificial Intelligence Management System
ISO/IEC 23894 — Artificial Intelligence Risk Management

OWASP

OWASP Top 10 for LLM Applications
OWASP Machine Learning Security
OWASP Software Supply Chain Security

European Union

EU AI Act
GDPR
European cybersecurity and digital regulation resources

37. Preguntas de comprobación

Pregunta 1

¿Cuál es la diferencia entre AI Governance y AI Security?

AI Security se centra en proteger los sistemas y datos frente a amenazas. AI Governance establece quién puede utilizar IA, con qué propósito, bajo qué condiciones, qué riesgos se aceptan y cómo se demuestra que los controles se cumplen.

Pregunta 2

¿Por qué un inventario de IA es un control de seguridad?

Porque permite descubrir sistemas desconocidos, asignar responsables, clasificar riesgos y determinar qué controles deben aplicarse. Un sistema que no conocemos no puede protegerse adecuadamente.

Pregunta 3

¿Qué diferencia existe entre una política y un control?

La política establece qué debe hacerse. El control establece cómo se comprueba que se está haciendo. Una implementación técnica y una evidencia permiten finalmente auditar el control.

Pregunta 4

¿Por qué las excepciones deben tener fecha de expiración?

Porque una excepción permanente se convierte en una nueva política informal y elimina la disciplina del sistema de control. La fecha obliga a revisar si el riesgo continúa siendo aceptable.

Pregunta 5

¿Cómo se relacionan AI-GRC y AI-SOC?

GRC define riesgos y controles; el SOC observa el entorno y detecta incidentes. La información de los incidentes debe volver al sistema de gobierno para actualizar riesgos, controles y políticas.

38. El modelo mental final

Este es el concepto que debe quedar después de completar toda la ruta Cybersecurity.

                  KNOW
                   │
                   ▼
                 ASSESS
                   │
                   ▼
                 PROTECT
                   │
                   ▼
                 VERIFY
                   │
                   ▼
                DEPLOY
                   │
                   ▼
                MONITOR
                   │
                   ▼
                DETECT
                   │
                   ▼
                RESPOND
                   │
                   ▼
                RECOVER
                   │
                   ▼
                GOVERN
                   │
                   ▼
                IMPROVE
                   │
                   └──────────────► KNOW

La idea fundamental

La seguridad de IA no es un proyecto. Es un sistema de gestión continuo.

El objetivo final no es conseguir que un auditor diga que una organización "cumple". El objetivo es construir una organización capaz de conocer sus sistemas de IA, comprender sus riesgos, aplicar controles, detectar desviaciones, responder ante incidentes y demostrar continuamente que sus controles funcionan.

39. Cierre de la ruta Cybersecurity

Con este módulo se completa la ruta avanzada de Cybersecurity.

01  Foundations
02  Threat Landscape
03  LLM Attacks
04  AI Red Team
05  LLM Security
06  RAG Security
07  AI Agents
08  AI APIs & Gateways
09  AI IAM
10  AI Data Security
11  AI Detection
12  AI-SOC
13  Incident Response
14  Security Architecture
15  Security Testing
16  Security Operations
17  AI Supply Chain Security
18  AI-GRC & Security Governance
                 │
                 ▼
        SECURE AI ORGANIZATION

Resultado esperado del alumno

Al terminar los 18 módulos, el alumno no debería limitarse a conocer vulnerabilidades de IA. Debe ser capaz de enfrentarse a una organización real y diseñar:

la arquitectura;
los controles;
el modelo de amenazas;
el SOC;
la Supply Chain;
el sistema de riesgos;
las políticas;
el gobierno;
la monitorización;
la respuesta ante incidentes;
la estrategia de cumplimiento;
y el modelo de mejora continua.

El objetivo final del curso es que el alumno sea capaz de construir y gobernar una organización preparada para utilizar IA sin convertir la IA en una superficie de ataque incontrolada.

1. Objetivos de aprendizaje

Competencias

2. ¿Qué es AI Governance?

No es únicamente Compliance

3. Modelo operativo de AI Security

RACI

4. AI Asset Inventory

Inventario mínimo

5. AI Risk Classification

Ejemplo de clasificación corporativa

LOW

MEDIUM

HIGH

CRITICAL

Modelo de scoring

6. AI Risk Management

Ciclo de gestión

Tratamiento del riesgo

7. AI Risk Register

8. Risk Appetite para IA

Ejemplo

9. AI Security Policies

Ejemplo

De política a control

10. Control Framework

11. NIST AI Risk Management Framework

Modelo conceptual

12. ISO/IEC 42001 e ISO 27001

Complementariedad

13. EU AI Act

Principio

14. IA y protección de datos

Preguntas que debe hacerse el arquitecto

15. AI Vendor Risk Management

Vendor assessment

16. Third-Party AI Assurance

Ejemplos

17. AI Approval Process

18. Exception Management

Una excepción debería incluir

19. Evidence Management

Ejemplos de evidencias

20. Continuous Compliance

21. AI Security Metrics

KPIs

KRIs

22. AI Security Dashboard

23. Integración entre GRC y AI-SOC

24. AI Incident Governance

Ejemplo

Proceso

25. AI Lifecycle Governance

26. Model Retirement

Checklist de retirada

27. Mapping entre frameworks

28. Laboratorio 1 — Crear un AI Risk Register

Escenario

Objetivo

Resolución orientativa

29. Laboratorio 2 — Diseñar una política corporativa de IA

Objetivo

Ejemplo de estructura

30. Laboratorio 3 — Diseñar un control auditable

Situación

Pregunta

Resolución

31. Laboratorio 4 — Auditoría de un sistema de IA

Escenario

Resolución

32. Laboratorio 5 — Diseñar un AI Security Governance Dashboard

Objetivo

33. Proyecto final — Enterprise AI Security Governance

Objetivo

El proyecto debe incluir

Arquitectura final

34. Evaluación final

35. Checklist profesional

36. Recursos y referencias

NIST

ISO