Cómo preparar su empresa para incidentes de IA

Si hay una constante en el mundo de la tecnología, es que cuanto más se adopta una tecnología, más falla. Este artículo trata sobre qué hacer ante incidentes de IA y cómo responder cuando ocurren.  Gran parte de este artículo se basa en la investigación que la firma Luminos.Law realizó para el Instituto Nacional de Estándares y Tecnología, así como en los conocimientos adquiridos en nuestro trabajo, centrado exclusivamente en la gestión de responsabilidades relacionadas con la IA. A lo largo del artículo se referirá a algunos incidentes específicos, pero cada uno de ellos se ha anonimizado para proteger la confidencialidad del cliente.

Respuesta a incidentes para sistemas de software tradicionales

La respuesta a incidentes para sistemas de software tradicionales (programados con miles o millones de líneas de código) se ha consolidado en las últimas dos décadas. Existe un manual de estrategias ampliamente aceptado para la respuesta a incidentes tradicionales. Sin embargo, no existe un manual similar para incidentes de IA. Hace casi una década, por ejemplo, Google creó una herramienta de IA que etiquetaba automáticamente objetos en imágenes, solo para descubrir que etiquetaba sistemáticamente a las personas negras como gorilas. Los marcos de respuesta a incidentes para sistemas de software tradicionales no habrían sido de mucha ayuda para responder a este tipo de incidente de IA.

De hecho, ni siquiera la definición tradicional de «incidente» para sistemas de software se aplicaba directamente a la IA. Así, por ejemplo, el NIST define un incidente en el contexto tradicional de la ciberseguridad:

Cualquier suceso que (1) ponga en peligro real o inminentemente, sin autorización legal, la integridad, confidencialidad o disponibilidad de la información o de un sistema de información; o (2) constituya una violación o amenaza inminente de violación de la ley, de las políticas de seguridad, de los procedimientos de seguridad o de las políticas de uso aceptable.

Esta definición se basa principalmente en la idea de que los incidentes son causados ​​por actores maliciosos que realizan acciones indebidas. Si bien estos actores pueden usar la IA para causar daños o atacar los propios sistemas de IA, estos generan nuevos tipos de daños que no requieren intenciones maliciosas. Esto, a su vez, implica que el manual tradicional de respuesta a incidentes debe actualizarse para los sistemas de IA. Entonces, ¿por dónde deberían empezar las organizaciones al prepararse para incidentes de IA? La respuesta está en las políticas de respuesta a incidentes.

Preparación para la respuesta a incidentes de IA

Dado que la respuesta a incidentes con IA difiere de la respuesta tradicional en varios aspectos, las iniciativas de respuesta a incidentes con IA requieren políticas y procedimientos propios para guiar a las empresas y al personal involucrado en la respuesta. Las políticas de respuesta a incidentes con IA deben abordar los siguientes aspectos.

Crear una definición de IA.

Esto podría parecer obvio en una política de respuesta a incidentes, pero muchas empresas han adoptado sistemas de IA y creado políticas de IA que no la definen adecuadamente. En general, mi firma define los sistemas de IA como modelos que realizan predicciones o generan contenido basándose en su capacidad para detectar patrones en los datos, lo cual coincide con la mayoría de las definiciones de sistemas modernos de IA o aprendizaje automático. Esto significa que, en la práctica, los modelos que no aprenden de los datos, como los sistemas tradicionales basados ​​en reglas, no deberían estar contemplados en las definiciones de IA.

Más importante aún, muchas empresas no definen claramente qué no es la IA, lo que puede dificultar saber cuándo confiar en políticas de respuesta a incidentes de IA frente a políticas y equipos de respuesta a incidentes más tradicionales. Para complicar aún más la situación, los sistemas de IA se implementan con frecuencia dentro de aplicaciones de software tradicionales; por ejemplo, un chatbot de IA integrado en una plataforma de software más grande. Saber dónde termina el sistema de software tradicional y dónde comienza el chatbot es fundamental.

Identificar los daños más relevantes.

Para algunas organizaciones, como las dedicadas a la robótica o el transporte, los daños físicos podrían ser los más relevantes. Otros daños importantes podrían estar relacionados con oportunidades económicas o cuestiones de equidad, algo que mi firma suele priorizar entre los clientes de servicios financieros y atención médica. La lista de posibles daños es larga y debe considerarse cuidadosamente al elaborar políticas y planificar la composición de los equipos de respuesta a incidentes.

Designar personas que respondan ante incidentes.

Organizaciones como el Instituto de Política y Estrategia de IA recomiendan personal con una combinación de experiencia, como TI, ciberseguridad, comunicaciones, derecho, unidades de negocio y expertos en el sector. También puede ser conveniente incluir recursos externos familiarizados con incidentes de IA, como asesores externos o consultores especializados en respuesta a incidentes de IA. Esto es especialmente útil cuando las empresas no cuentan con los recursos internos necesarios para responder plenamente a sus propios incidentes de IA.

Desarrollar un plan de contención a corto plazo.

Una vez establecidas las políticas de respuesta a incidentes, la siguiente y más importante parte de la respuesta a incidentes de IA consiste en desarrollar planes para contener el impacto negativo de un incidente lo antes posible. Este plan solo debe abordar cómo contener el incidente a corto plazo mientras se desarrollan estrategias de respuesta a largo plazo. El plan debe estar listo antes de la implementación efectiva de un modelo.

Estos planes consisten en instrucciones generales sobre cómo modificar los sistemas de IA una vez implementados para mitigar los daños que cualquier incidente pueda causar. También deben describir todas las dependencias posteriores del sistema, de modo que modificar su comportamiento no genere cambios inesperados en otros modelos o aplicaciones que interactúan con la IA.

Comprender cómo y por qué falla un sistema de IA es un proceso largo y arduo. Comprender por completo el origen de un incidente de IA puede llevar semanas o incluso meses. Un cliente no tenía un plan similar cuando descubrió que una herramienta de selección de RR. HH. basada en IA, utilizada para evaluar a los solicitantes de empleo, estaba dando un trato preferencial a un grupo demográfico específico. Como resultado, sus líderes se encontraron en un punto muerto: podían seguir usando la herramienta y permitir que los daños persistieran, o podían desactivarla. Al final, optaron por desactivar el sistema de IA, que permaneció fuera de servicio durante más de un año. Si hubieran tenido un plan de contención a corto plazo, podrían haber reducido el uso de la herramienta o modificarla para comprender el origen del incidente y todas las opciones para contenerlo.

Identificación rápida de incidentes

Identificar incidentes rápidamente puede ser complicado. Como se mencionó anteriormente, los actores maliciosos no siempre son la causa; los sistemas de IA son probabilísticos, lo que significa que se garantiza que se equivocarán y realizarán comportamientos no deseados en un cierto porcentaje de las ocasiones. En consecuencia, los incidentes pueden surgir simplemente durante el uso normal de los sistemas de IA. Si bien ningún método de detección es infalible, existen diversas herramientas y enfoques que pueden ayudar a identificar incidentes de IA en la práctica. El primero, llamado «apelación y anulación», es una funcionalidad que, como la describe el NIST, permite a los usuarios «utilizar canales fáciles de usar, como formularios de comentarios, correos electrónicos o líneas directas… para informar problemas, inquietudes» o «resultados no deseados para incorporarlos a las prácticas de monitoreo».

Dar a los usuarios la capacidad de marcar comportamientos inapropiados o indeseables del sistema permite que aquellos que más interactúan con el sistema cumplan una función de alerta.

Además de las capacidades de apelación y anulación, las empresas también pueden utilizar sistemas de monitoreo de modelos y configurar alertas para comportamientos anómalos o problemáticos. Las directrices emitidas por los gobiernos de Canadá, el Reino Unido, Australia y Estados Unidos a principios de este año exigieron específicamente este tipo de monitoreo para garantizar la seguridad de la IA.

Por último, las pruebas realizadas por partes internas o externas, idealmente, incluso antes de la implementación del sistema de IA, pueden revelar problemas. Un enfoque similar es el «equipo rojo», en el que un grupo independiente de los científicos de datos que desarrollaron el sistema intenta atacarlo o provocar que haga algo perjudicial.

Qué hacer tras identificar un incidente de IA: contención, erradicación y recuperación

Una vez identificados los incidentes, el siguiente paso es implementar una estrategia de contención a largo plazo para evitar que el daño se propague aún más. Estas son las preguntas clave que dicha evaluación debería responder:

¿Quién está siendo perjudicado?

Dado que la definición de un incidente de IA se centra en los daños reales o potenciales, comprender quién está siendo perjudicado y en qué medida se producen es una de las primeras preguntas que las empresas deben responder. Poco después de implementar un sistema de IA generativa, un cliente descubrió que el sistema se había entrenado con grandes cantidades de datos problemáticos, incluyendo materiales con derechos de autor y datos personales recopilados sin el consentimiento de los usuarios. En este caso, un científico de datos interno detectó el error después de implementar el modelo, algo muy común cuando los equipos legales no participan en las primeras etapas del desarrollo del modelo. La empresa necesitaba comprender rápidamente de quién eran los datos que se habían incorporado al sistema de IA y qué leyes aplicaban.

¿Cuáles son las opciones para modificar el comportamiento del sistema de IA?

Si las empresas tienen suerte, puede haber varias opciones para cambiar el comportamiento del sistema de forma rápida y fiable, especialmente si la IA no tiene numerosas dependencias, tanto ascendentes como descendentes. El Instituto de Política y Estrategia de IA (IA) elaboró ​​una taxonomía específica para este tipo de opciones, que abarca desde restringir cada sistema de IA a un conjunto específico de usos, como usar un modelo para usos internos pero prohibir su uso para consumidores, hasta apagar todo el sistema. Si los datos utilizados para entrenar el modelo son problemáticos, como el sistema de IA generativa de nuestro cliente, algunos métodos de vanguardia pueden enseñar al modelo a «desaprender» aquello con lo que fue entrenado.

¿Qué está causando el daño?

Detectar y erradicar a los actores maliciosos suele ser más sencillo que predecir y corregir aspectos como el sesgo involuntario presente en los datos de entrenamiento o incorporado en la propia arquitectura del modelo. En cualquier caso, comprender cómo surgió el daño (de los atacantes, los datos de entrenamiento, la arquitectura del modelo, etc.) es importante para las siguientes fases de la respuesta a incidentes.

¿Es posible abordar o rectificar de algún modo los daños existentes?

Una vez ocurrido el incidente, es importante no solo comprender quiénes se han visto perjudicados, sino también qué pueden hacer las empresas al respecto. Un tipo común de incidente surge cuando se ofrecen servicios preferenciales, como descuentos en productos, solo a grupos demográficos específicos.

Una vez implementados y ejecutados los planes de contención, el siguiente paso consiste en intentar eliminar por completo la causa del incidente. Algunos sistemas de IA pueden ser compatibles con los esfuerzos de erradicación, pero otros solo permiten una erradicación parcial o incluso no pueden eliminar la fuente del incidente. A grandes rasgos, existen tres maneras principales de abordar o corregir el comportamiento problemático de los modelos, cada una de las cuales se ha utilizado durante mucho tiempo para depurar modelos de aprendizaje automático:

• • Preprocesamiento.

Esto se relaciona con las acciones que se pueden realizar antes de que el modelo ingiera o se entrene con los datos de entrada. En algunos casos, los datos de entrenamiento no representativos pueden ser la causa de un comportamiento problemático del modelo. En ese caso, la solución es volver a entrenar el modelo con datos de entrenamiento más representativos.

• • En procesamiento.

Este tipo de correcciones implican cambiar los pesos o la arquitectura del propio modelo. A veces, estas actualizaciones son relativamente sencillas, pero la mayoría de las veces requieren un desarrollo considerable y laborioso. Rara vez he visto que este enfoque funcione en la práctica, principalmente porque suele implicar la creación de un modelo completamente nuevo.

• • Postprocesamiento.

Esta es la opción más sencilla y se ha utilizado ampliamente para solucionar problemas de IA durante décadas . Implica cambiar el comportamiento del modelo después de que el sistema haya realizado sus predicciones. Los filtros de salida, por ejemplo, pueden simplemente deshabilitar algún comportamiento o impedir que se generen predicciones específicas. Estos suelen consistir en reglas que se pueden añadir al modelo. Esa fue la solución que Google implementó para abordar la herramienta de IA que etiquetaba a los negros como gorilas: su solución fue prohibir que el sistema identificara gorilas, incluidas fotos de gorilas reales.

Lecciones aprendidas

Tras finalizar las actividades de respuesta, es fundamental que las empresas realicen una revisión post mortem para aprender y mejorar de cada incidente. Esta consiste en analizar en perspectiva los aciertos y errores de la gestión del incidente.

Este tipo de revisión implica tomar las siguientes acciones, muchas de las cuales son las mismas que se deben utilizar en las revisiones realizadas después de la recuperación de los ciberataques a los sistemas de software tradicionales.

• Convoque a los equipos de respuesta al incidente lo más rápidamente posible (quizás unos pocos días después de que concluya el incidente) para evaluar el incidente en general.
• Asegúrese de que todas las lecciones aprendidas, tanto las positivas como las negativas, queden por escrito para que puedan consultarse posteriormente. Pensar en qué información debe ser privilegiada también es un factor clave en este proceso.
• Solicite la retroalimentación del grupo más amplio posible de participantes. Si bien el personal de respuesta es fundamental para la respuesta al incidente, otros profesionales suelen estar muy involucrados, como abogados, científicos de datos, unidades de negocio y TI.
• Actúe según la retroalimentación. Obviamente, las lecciones aprendidas solo son útiles si se implementan.

La prevención y la respuesta a los riesgos deben ser una actividad continua. Una vez implementadas las lecciones aprendidas, se recomiendan ejercicios de simulación, capacitaciones y la formación de equipos de respuesta.

Todas estas actividades pueden parecer complicadas y consumir muchos recursos. He hablado con muchos científicos de datos sobre la respuesta a incidentes de IA, quienes temen que el tipo de enfoque que he descrito en este artículo pueda ralentizar la adopción de la IA. Pero la realidad es la contraria. En la industria automotriz, se suele decir que son los frenos, no los motores, los que permiten que los autos vayan rápido. Son los frenos los que dan a los conductores la confianza para acelerar, porque saben que pueden reducir la velocidad cuando sea necesario. De igual manera, saber cómo responder cuando las cosas salen mal es lo que acelerará la adopción de la IA. Andrew Burt es cofundador de Luminos.Law

 

---

Texto con traducción automática de Google.

---

Tomado de:
Harvard Business Review. AI and machine learning. How to Prepare Your Company for AI Incidents. Recuperado de: www.hbr.org