Claves de la gestión integral de la IA empresarial: inventario real, MLOps y ciberseguridad en todo el ciclo de vida

Muchas empresas ya usan inteligencia artificial sin saberlo del todo: basta con que una herramienta de oficina incorpore un asistente nuevo tras una actualización. Ese desconocimiento, identificado como shadow AI, fue una de las principales alertas de Gustavo Vallejo, profesional con más de 25 años de trayectoria internacional liderando la arquitectura de seguridad, la ciberseguridad y el gobierno de TI, durante un evento de ciberseguridad organizado por Open-Sec.

Qué es un sistema de IA y por qué importa conocerlo

Vallejo partió de una definición estándar: un sistema de ingeniería que genera resultados, predicciones, contenidos, recomendaciones o soluciones para un conjunto de objetivos definidos por humanos. Bajo ese paraguas caben el machine learning, el deep learning, el procesamiento del lenguaje natural, las redes neuronales y la IA generativa, con sus modelos de lenguaje (LLM). Los agentes de IA, hoy muy utilizados, combinan varios de estos componentes.

Para el especialista, lo primero es entender qué tipo de sistema se tiene, cómo se obtuvo (construido, comprado o alquilado) y bajo qué modelo se despliega: infraestructura propia, IaaS, PaaS o SaaS. Cada opción cambia las tareas de gestión de TI y de ciberseguridad. También es clave ubicar en qué punto del ciclo de vida interviene la organización. “Probablemente amanecimos con un sistema de IA ya entregado y estemos en operación y mantenimiento”, ejemplificó, lo que obliga a conocer cómo se construyó.

Estimó, además, que entre el 50 % y el 60 % de los proyectos de IA tiene que ver con los datos: su origen, su calidad y si son sintéticos o adquiridos.

Supervisión, responsabilidad e inventario

Vallejo subrayó la necesidad de definir la supervisión humana, incluido un botón de parada o “kill switch” cuando el sistema sea de nivel crítico, y una cadena de responsabilidad documentada para los casos en que la IA cometa errores, sesgos o inequidades.

Otro problema que observa es que muchas empresas no conocen realmente qué IA tienen. Ocurre, por ejemplo, cuando una herramienta ofimática incorpora de pronto un asistente de IA. A ello se suman los productos de gestión de TI y de ciberseguridad que ya traen componentes de IA. El inventario, insistió, debe ser real, porque ha habido ciberataques en los que una IA no registrada (shadow AI) facilitó el trabajo a los delincuentes.

Riesgos y confiabilidad

Entre los riesgos mencionó el sesgo y la discriminación derivados de la calidad de los datos, los ataques adversariales, el envenenamiento de datos, los problemas de privacidad, la falta de explicabilidad de los modelos “caja negra”, la cadena de suministro de datos de terceros y el drift, es decir, la desviación del comportamiento del modelo respecto a su entrenamiento.

Para hablar de una IA confiable, planteó seis parámetros mínimos: calidad, linaje y gobernanza del dato; transparencia y explicabilidad; ética, justicia y equidad; resiliencia; seguridad física (safety) y privacidad.

También advirtió contra la moda de automatizar procesos con IA como si fuera una novedad, cuando ya se hacía con BPM y RPA desde 2010. Sin casos de uso bien documentados, las demos y pruebas de concepto pueden generar problemas dentro de la empresa.

Gestión de TI: MLOps

Según Vallejo, no se trata de crear procesos nuevos, sino de integrar los existentes bajo la práctica de MLOps (machine learning operations), que permite desarrollar, desplegar y operar modelos de forma reproducible, observable y controlada. Esto exige perfiles distintos en las áreas de TI, con observación y control permanentes.

Los cuatro bloques que identificó son gestión de cambios, gestión de entregas, operación y monitoreo, y gestión de incidentes. En cambios, recomendó rastrear el linaje completo y mantener control de versiones para poder volver a una versión estable si una nueva se lanzó sin las pruebas necesarias. También pidió considerar el ciclo de vida del hardware, como las GPU en infraestructura propia.

En la operación, el monitoreo abarca consumo de memoria, rendimiento de las API y latencia de las predicciones. Compartió que, en pruebas con un LLM de código abierto en su propio equipo, el consumo de GPU llegó a apagar la computadora. Lo que más se teme, señaló, es el drift de datos y de concepto. Ante fallas, debe existir un rollback definido desde el inicio, automático o con apagado manual, y análisis de causa raíz en un entorno aislado.

Vallejo recomendó además evitar las zonas grises de responsabilidad: definir quién es el sponsor, el dueño del modelo y los responsables de datos, plataforma y seguridad, y delimitar el ámbito de TI. También sugirió acordar niveles de servicio, como la latencia de respuesta, que depende del hardware, y ser explícito con los proveedores, que podrían deslindarse si los datos entregados tenían sesgos. Señaló asimismo que en algunos países, como los de la Unión Europea, se exige probar los sistemas en entornos sandbox, algo que no ha visto la normativa peruana.

Ciberseguridad: Secure MLOps

Para el área de seguridad, dijo, los conceptos de confidencialidad, integridad y disponibilidad se quedan cortos. Propuso el enfoque de Secure MLOps, que cubre todo el ciclo de vida del sistema, sea propio o adquirido, y no solo el monitoreo con un SIEM. Lo resumió en cuatro prácticas:

• Desarrollo seguro: análisis de vulnerabilidades en el código, entornos aislados con contenedores o máquinas virtuales y almacenamiento seguro de credenciales.
• Entrenamiento seguro: control de los datos de entrada para evitar su envenenamiento y firmado de artefactos con huellas hash criptográficas antes de pasar a producción.
• Despliegue protegido: escaneo de contenedores en busca de vulnerabilidades conocidas (CVE) y seguridad en las API que se comunican con otros proveedores.
• Monitoreo y defensa en producción: detección de extracción de modelos, ataques de evasión, deriva de datos y sesgo inyectado, además de auditorías y logs centralizados.

Entre los riesgos más relevantes mencionó la fuga de datos, favorecida por la falta de inventario o de pruebas, y la extracción de modelos mediante otros modelos. Dio un ejemplo de envenenamiento simple: candidatos que ocultaron en su hoja de vida, con letras en blanco, instrucciones dirigidas a sistemas de IA que evalúan postulantes para mejorar su puntaje.

Para evaluar estos sistemas, recomendó apoyarse en marcos como MITRE ATLAS y el Top 10 de OWASP para IA, y no limitarse a medir la precisión, sobre todo cuando atenderán a usuarios externos.

Vallejo cerró recordando la importancia de conocer las obligaciones de la ley de IA, en particular para los sistemas de alto riesgo, que la normativa peruana ya contempla.

Seguiremos brindándote más información sobre este tema en las siguientes presentaciones físicas y digitales de Channel News Perú

Mantente conectado a nuestra plataforma de negocios y revista, haciendo clic aquí y suscribiéndote a nuestro newsletter para contenido de valor diario