CYNTHUS Expert Series: IA bajo control | Gobierno de la inteligencia artificial, ciberseguridad y continuidad

Respuesta: Para diseñar e implementar un modelo de gobierno ayuda mucho tener los conocimientos de Gobierno de TI y del marco de trabajo de COBIT, para su especialización en Gobierno de IA, conocer la norma ISO 42001 y mejor si obtiene una educación formal de ISO 42001 Implementador.

Al final es importante tener diversas perspectivas con buenas prácticas como ITIL, que su versión 5 ya es nativa para IA, le incorporaron conceptos y modelos de IA a las prácticas y procesos de gestión de servicios y productos.

En el caso del PMBOK está incorporando también conceptos de IA y han liberado en el PMI varios documentos al respecto.

Lo importante es ir conociendo diferentes propuestas que ayudan al gobierno y gestión de la IA y seleccionar las que hagan sentido para nosotros y nuestras organizaciones.

Respuesta: Efectivamente algunas de las certificaciones de ISACA para IA tienen como requerimiento ser CISA o CISM/CISSP, existe el certificado de “AI Fundamentals Certificate” que no tiene ese prerrequisito.

El ISO 42001 y las certificaciones avanzadas de IA de ISACA cumplen objetivos complementarios y sus cuerpos de conocimiento son diferentes, se comparten algunos conceptos pero en general las veo como complemento.

Respuesta: Es muy bueno tener el apoyo y patrocinio de la gerencia general para el uso de la IA pero también tener un modelo de gobierno de la IA que permita efectivamente aprovechar las oportunidades que nos ofrece y los riesgos.

Existe un enfoque que considero adecuado y es pasar de procesos a flujos de valor el cual nos ayuda a identificar en que parte de las actividades esenciales (de valor) la IA nos genera el mayor beneficio. Esto se puede hacer con esfuerzos de lean management o arquitectura empresarial /negocio. Y complementa a la gestión por procesos.

Es importante seleccionar una buena práctica de gestión del cambio organizacional, puedes utilizar COBIT y/o ADKAR/PROSCI y/o ITIL Mejora Continua/Transformación.

Antes del AsIS y el ToBe es recomendable el porqué y para qué, es ideal justificar la iniciativa o proyecto explicando el valor, los beneficios, motivadores, riesgos e inversiones.

Respuesta: Depende del país y región. Sugiero hablar del tema con las personas de legal y cumplimiento de la organización. Ya están legislando en algunos países/regiones pero están en proceso,

Considero importante que se analicen las consecuencias por el mal uso de la IA (la información de entrada y salidas, las decisiones y modelos con sus sesgos) y sobre todo identificar el impacto para los clientes, proveedores y socios, ya que no solo los reguladores generan consecuencias.

Respuesta:  Las decisiones de uso de la IA y de sus resultados deben ser asignadas a niveles superiores de la organización. Si todavía no se tiene un responsable como un Chief IA Officer, tanto en TI como el negocio debemos poner el tema sobre la mesa a los directivos para que definan el camino a seguir y la postura. Como colaboradores de la empresa recomiendo esperar a esa autorización para evitarnos problemas tanto en lo personal como para la organización.

Respuesta: No es obligatorio, ese es el enfoque que le podemos dar y nos ayuda mucho para integrar a los estándares, frameworks y regulaciones, pero podemos únicamente seguir el camino vía los ISOs.

También podemos usar ITIL 5 que incorpora elementos de Gobierno y Gestión de IA pero con un enfoque a productos y servicios.

La idea es identificar los estándares, buenas prácticas, etc., que están disponibles y adoptar y adaptar a nuestra organización según los requerimientos y necesidades.

Respuesta: Puede ser, especialmente por valoraciones y niveles de inversión que anticipan beneficios que aún no llegan a materializarse. Pero no considero que la IA sea una burbuja tecnológica, ya que el riesgo está en las expectativas financieras y retorno de inversión.

Mi lectura: el problema no es invertir en IA, sino invertir sin casos de negocio medibles y esperar ROSI demasiado rápidos.

Respuesta: Sí, ya existen herramientas bastante maduras. Pero tendría cuidado con la palabra «certificada». Una herramienta puede ayudar a cumplir ISO/IEC 42001, NIST AI RMF o el AI Act europeo que hablamos en la charla.

Respuesta: Yo empezaría por definir exactamente para qué puede usarse la IA y para qué no, es conocer el proceso y el flujo. Luego limitaría los accesos, qué información puede recibir y qué acciones puede ejecutar. Y todo debería quedar registrado y monitoreado, para la trazabilidad.

Respuesta: Sí, aunque en nuestros países todavía no tengan una ley específica de IA, yo tomaría como referencia regulaciones más avanzadas de otros países y estándares internacionales. Eso permite anticiparse a futuras exigencias y adoptar buenas prácticas desde ahora.

Respuesta: Sí, claro, por ejemplo: advertencias, suspensión, restricción del uso de un sistema de IA, retiro del sistema y medidas disciplinarias internas. El AI Act europeo contempla expresamente medidas no monetarias.

Respuesta: Totalmente. Yo lo veo como cualquier tecnología muy potente, más de que emergente: mientras más capacidad tiene, mayor debe ser el control.

Ya existen ataques entre los mismos modelos, y también usos maliciosos para phishing, fraude, suplantación y ciberataques.

Por eso, la seguridad debe incorporarse desde que se diseña y adopta la IA, no reactivo.

Respuesta: No debería decidirse por edad ni generación porque ahí justamente podemos introducir sesgos.

Yo usaría la IA para evaluar aspectos objetivos del candidato, como estabilidad laboral previa, competencias y experiencia. La decisión final debería mantenerse bajo supervisión humana.

Respuesta: Yo lo haría colocando una capa central entre los usuarios y los modelos de IA, que son Guardrails, como un «AI Gateway». Todos los prompts pasan primero por ahí. También hay DLPs para IA.

Eso permite registrar quién consulta, qué información envía, y bloquear prompts que incumplan las políticas antes de que lleguen al modelo.

Respuesta: Yo lo manejaría desde cuatro frentes: gobierno de IA, controles de seguridad, capacitación de los usuarios y monitoreo permanente.

La idea es identificar los riesgos antes de implementar la IA, establecer controles según el nivel de riesgo y mantener supervisión durante todo su uso

Respuesta: Para evitar Shadow AI, yo manejaría un inventario centralizado y definiría un responsable por cada herramienta de IA. También implementaría descubrimiento automático para detectar herramientas que los usuarios estén utilizando sin autorización.

Respuesta: Exactamente. Yo tendría un inventario de las herramientas de IA autorizadas, indicando para qué pueden utilizarse y qué información pueden procesar.

Respuesta: Se puede usar Guardrails, que analiza cada prompt para detectar intentos de «prompt injection», después revisa la respuesta para evitar fugas de información o acciones peligrosas.

Todo esto conectado al SIEM para generar alertas automáticas y poder investigar los eventos sospechosos.

Da click en desplegar para ver la respuesta.

Respuesta: No creo que exista como tal una póliza específica para riesgos de IA; sin embargo, podrías preguntar a una aseguradora sobre las coberturas que maneja una póliza de Seguro de Interrupción de Negocios, misma que puede estar integrada dentro de un Seguro Múltiple Empresarial, la cuál podría cubrir aspectos como: Pérdida de ingresos, gastos de operación fijos y gastos extraordinarios o de reubicación.

Respuesta: Generalmente el Shadow AI es consecuencia de una debilidad en gobernabilidad de la IA, o la falta de políticas sobre la adquisición y la gestión de la IA. Aunque suele no ser tan complicado implementar controles que reduzcan o eviten la generación de Shadow AI, sí se requiere de un esfuerzo de definición e implementación de políticas y controles. Por ejemplo, la definición de políticas estrictas que definan roles, responsabilidades y consecuencias, que prohíban a las áreas de negocio adquirir tecnología sin la aprobación de TI (incluyendo licencias de SW y servicios de terceros – dentro de ellos estarían los proveedores de AI), de tal manera que TI sería la única entidad autorizada para adquirir este tipo de servicios o herramientas.

Respuesta: Las etapas como tal siguen siendo las mismas: Recuperación ante Desastres (DR) se enfocará en el restablecimiento de la infraestructura tecnológica y servicios de TI, mientras que la Continuidad de Negocio (BC) se enfocará en la continuidad operativa y la toma de decisiones. Ante la integración de la Inteligencia Artificial, ambos elementos DR y BC deberán interactuar en conjunto para establecer procedimientos de recuperación (DR), así como los planes de continuidad (BC) que permitan una respuesta coordinada, ante la ocurrencia de incidentes algorítmicos.

Respuesta: Hablando con el proveedor del servicio de IA y revisando los términos y condiciones establecidos en el contrato. Es probable que existan ciertos controles que eviten la exposición de datos de sus clientes; sin embargo, dichos controles deberían ser revisados por las áreas de Legal, Normatividad, Gobernabilidad o Auditoría, de tal forma que aseguren que se encuentran dentro de parámetros aceptables de protección de la confidencialidad y la privacidad de la información.

Respuesta: Efectivamente, el contar con aspectos como acuerdos de niveles de servicio (SLAs), penalización por incumplimiento, pruebas, informes, auditorías, entre otros, puede ayudar a reducir los riesgos de interrupción de los servicios de IA, aunque eso no garantiza la disponibilidad ni evita las interrupciones. Es por ello por lo que debemos implementar estrategias de recuperación (en el caso de DR) y estrategias de Fallback (en el caso de IA) que permitan la continuidad operativa.

Respuesta: Es correcto. Tanto el DRP, como los BCPs deben trabajar en conjunto para restablecer los sistemas y procesos críticos que integran servicios de IA. Adicionalmente, deben definirse medidas de contención y operación en contingencia, alineando los procedimientos con los RTOs técnicos y los RTOs de negocio (incluyendo Fallback manual con intervención humana y un nivel de servicio degradado previamente definido).