Cómo preparar a su empresa para los incidentes de IA

Si hay una constante en el mundo de la tecnología, es que cuanto más se adopta una tecnología determinada, más se rompe. Este artículo trata sobre qué hacer con los incidentes de la IA y cómo responder a ellos cuando se producen.

Gran parte de este artículo proviene de una investigación de mi empresa, Luminoso. Ley, realizado para el Instituto Nacional de Estándares y Tecnología, así como la información recopilada por nuestro trabajo, que se centra exclusivamente en la gestión de las responsabilidades de la IA. A lo largo de este artículo me referiré a algunos incidentes específicos, pero cada uno ha sido anonimizado para proteger la confidencialidad del cliente.

Respuesta a incidentes para sistemas de software tradicionales

La respuesta a los incidentes en los sistemas de software tradicionales (los que se programan con miles o millones de líneas de código) se ha convertido en un campo maduro en las últimas dos décadas. Hay un manual de estrategias ampliamente aceptado para la respuesta tradicional a los incidentes. Pero no existe ese manual de estrategias para los incidentes de la IA. Hace casi una década, por ejemplo, Google creó una herramienta de inteligencia artificial que etiquetaba automáticamente los objetos de las imágenes, solo para descubrir que etiquetó constantemente a los negros de gorilas. Los marcos de respuesta a los incidentes de los sistemas de software tradicionales no habrían ayudado mucho a nadie a responder a este tipo de incidentes de IA.

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

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

Esta definición se basa en gran medida en la idea de que los incidentes son causados por malos actores que hacen cosas malas. Si bien los malos actores pueden utilizar la IA para crear daños o atacar a los propios sistemas de IA, los sistemas de IA provocan nuevos tipos de daños que no requieren mala intención. Esto, a su vez, significa que hay que actualizar el manual tradicional de respuesta a los incidentes para los sistemas de IA. Entonces, ¿por dónde deberían empezar las organizaciones a la hora de prepararse para los incidentes de IA? La respuesta está en las políticas de respuesta a los incidentes.

Preparándose para la respuesta a los incidentes de la IA

Como la respuesta a los incidentes de la IA es diferente de la respuesta tradicional a los incidentes en varios sentidos, las iniciativas de respuesta a los incidentes de la IA requieren sus propias políticas y procedimientos para guiar a las empresas y al personal implicado en la respuesta al incidente. Las políticas de incidentes de la IA deben abordar lo siguiente.

Cree una definición de IA.

Esto puede parecer una parte obvia de una política de respuesta a incidentes, pero muchas empresas han adoptado sistemas de IA y han creado políticas de IA que no definen suficientemente la IA. A un alto nivel, mi empresa define los sistemas de IA como modelos que hacen predicciones o generan contenido en función de su capacidad de detectar patrones en los datos, lo que se ajusta a la mayoría de las definiciones de los sistemas modernos de IA o aprendizaje automático, lo que significa que, en la práctica, los modelos que no aprenden de los datos, como los sistemas tradicionales basados en reglas, no deberían incluirse en las definiciones de la IA.

Y lo que es más importante, muchas empresas no definen claramente qué es la IA no lo es, y esto puede hacer que sea más difícil saber cuándo confiar en las políticas de respuesta a los incidentes de la IA que en las políticas y los equipos más tradicionales de respuesta a los incidentes. Para complicar las cosas, los sistemas de IA se despliegan con frecuencia en las 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.

Identifique los daños más relevantes.

Para algunas organizaciones, como las que se dedican a la robótica o el transporte, los daños físicos pueden ser los más relevantes. Otros daños importantes podrían estar relacionados con las oportunidades económicas o con las cuestiones de equidad, algo que mi empresa normalmente ve priorizado por los clientes de servicios financieros y de atención médica. La lista de posibles daños es larga y hay que pensarla detenidamente a la hora de elaborar las políticas y pensar en la composición de los equipos de respuesta a los incidentes.

Designe a los socorristas.

Organizaciones como el Instituto de Política y Estrategia de la IA recomendar personal con una combinación de experiencia, como expertos en TI, ciberseguridad, comunicaciones, legal, unidades de negocio y dominios. También podría tener sentido incluir recursos externos familiarizados con los incidentes de la IA, como abogados o consultores externos especializados en la respuesta a los incidentes de la IA. Esto es especialmente útil cuando las empresas no tienen los recursos internos necesarios para responder plenamente a sus propios incidentes de IA.

Desarrolle un plan de contención a corto plazo.

Una vez establecidas las políticas de respuesta a los incidentes, la siguiente y más importante parte de la respuesta de la IA a los incidentes consiste en desarrollar planes para contener el impacto perjudicial de un incidente lo antes posible. Este plan solo tiene que abordar cómo contener el incidente a corto plazo y, al mismo tiempo, se pueden desarrollar estrategias de respuesta a largo plazo. El plan debería estar listo antes de que se despliegue realmente un modelo.

Estos planes consisten en instrucciones de alto nivel sobre cómo modificar los sistemas de IA una vez desplegados para reducir los daños que causa cualquier incidente. También deberían describir todas las dependencias posteriores del sistema, de modo que cambiar el comportamiento del sistema no provoque cambios inesperados en otros modelos o aplicaciones que interactúan con la IA.

[

Insight Center Collection

Collaborating with AI

How humans and machines can best work together.

](/insight-center/collaborating-with-ai)

Entender cómo y por qué un sistema de IA falla es un proceso largo y arduo. Pueden pasar semanas o incluso meses entender completamente el origen de un incidente de IA. Un cliente no tenía ese plan cuando descubrió que una herramienta de selección de recursos humanos basada en la IA que se utilizaba para evaluar a los solicitantes de empleo daba un trato preferencial a un grupo demográfico específico. Como resultado, sus líderes se encontraron en un punto muerto: podían seguir utilizando la herramienta y permitir que los daños continuaran, o podían cerrarla. Al final, decidieron cerrar el sistema de IA y estuvo desconectado durante más de un año. Si hubieran tenido un plan de contención a corto plazo, podrían haber podido reducir el uso de la herramienta o modificarla de manera que pudieran entender el origen del incidente y todas las opciones para contenerlo.

Identificar los incidentes rápidamente

Identificar los incidentes rápidamente puede resultar difícil. Como se ha dicho anteriormente, los actores malintencionados no siempre son la causa; los sistemas de IA son probabilísticos, lo que significa que se equivocan y se involucran en conductas no deseadas un porcentaje de las veces. En consecuencia, los incidentes pueden surgir simplemente en el curso normal de las personas que utilizan los sistemas de IA. Si bien ningún método de detección es infalible, hay un puñado de herramientas y enfoques que pueden ayudar a identificar los incidentes de la IA en la práctica. La primera, llamada «apelar y anular», es una funcionalidad que, como El NIST lo describe, permite a los usuarios «emplear canales fáciles de usar, como formularios de comentarios, correos electrónicos o líneas directas… para denunciar problemas, inquietudes» o «resultados no deseados para alimentar las prácticas de supervisión».

Dar a los usuarios la posibilidad de marcar un comportamiento del sistema inapropiado o no deseado permite a quienes más interactúan con el sistema funcionar como función de alerta.

Además de confiar en las capacidades de apelación e anulación, las empresas también pueden utilizar sistemas de supervisión de modelos y configurar alertas para comportamientos anómalos o problemáticos. Guía publicada por los gobiernos de Canadá, el Reino Unido, Australia y los Estados Unidos a principios de este año específicamente pedido este tipo de monitorización para garantizar la seguridad de la IA.

Por último, las pruebas realizadas por partes internas o externas (idealmente, incluso antes de que se despliegue el sistema de IA) pueden sacar a la luz problemas. Uno de esos enfoques es «equipo rojo» en el que un grupo independiente de los científicos de datos que desarrollaron el sistema intenta atacar el sistema 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 llevar a cabo una estrategia de contención a más largo plazo para evitar que el daño se propague aún más. Estas son las preguntas fundamentales a las que debe responder una evaluación de este tipo:

¿Quién está siendo perjudicado?

Dado que la definición de incidente de IA se centra en los daños reales o potenciales, entender quién sufre los daños y el grado en que se producen esos daños es una de las primeras preguntas que deben responder las empresas. Poco después de implementar un sistema de IA generativa, un cliente se enteró de que el sistema había sido entrenado con enormes cantidades de datos problemáticos, incluidos materiales con derechos de autor y datos personales que se habían recopilado sin el consentimiento de los usuarios. En este caso, un científico de datos interno se dio cuenta del error tras el despliegue del modelo, lo cual es muy común cuando los equipos legales no participan al principio del ciclo de vida del desarrollo del modelo. La empresa necesitaba entender rápidamente qué datos se habían incorporado al sistema de IA y qué leyes se aplicaban.

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

Si las empresas tienen suerte, puede que haya un puñado de opciones para cambiar el comportamiento del sistema de forma rápida y fiable, especialmente si la IA no tiene varias dependencias ascendentes o descendentes. El Instituto de Política y Estrategia de la IA creó una taxonomía específica para este tipo de opciones, que van desde restringir cada sistema de IA a solo un conjunto específico de usos, como usar un modelo para usos internos pero no permitir su uso a los consumidores, hasta cerrar todo el sistema. Si los datos utilizados para entrenar el modelo son problemáticos, como lo era el sistema de IA generativa de nuestro cliente, algunos métodos vanguardistas puede enseñar el modelo para «desaprender» en qué se entrenó.

¿Qué es lo que causa el daño?

Encontrar y erradicar a los malos actores tiende a ser más sencillo que predecir y corregir cosas como el sesgo no deseado contenido en los datos de entrenamiento o incorporado a la propia arquitectura del modelo. En cualquier caso, entender cómo se produjo el daño (de los atacantes, los datos de entrenamiento, la arquitectura del modelo y más) es importante para las siguientes fases de la respuesta al incidente.

¿Se pueden abordar o corregir los daños existentes de alguna manera?

Una vez ocurrido el incidente, es importante no solo entender quién ha sufrido los daños, sino qué pueden hacer las empresas al respecto. Un tipo de incidente común se produce cuando los servicios preferenciales, como descuentos en productos, solo se ofrecen a grupos demográficos específicos.

Una vez establecidos y ejecutados los planes de contención, el siguiente paso es intentar eliminar por completo la causa del incidente. Algunos sistemas de IA pueden ser aptos para los esfuerzos de erradicación, pero otros sistemas solo permiten la erradicación parcial o puede que la fuente del incidente no pueda eliminarse en absoluto. En un nivel alto, hay tres formas principales para abordar o corregir el comportamiento problemático del modelo, cada uno de los cuales tiene usado durante mucho tiempo para depurar modelos de aprendizaje automático:

Preprocesamiento.

Esto se refiere a cosas que puede hacer antes de que la modelo ingiera o se entrene con los datos de entrada. En algunos casos, los datos de entrenamiento poco representativos pueden ser la fuente del 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 proceso.

Este tipo de correcciones implican cambiar los pesos o la arquitectura reales del propio modelo. A veces este tipo de actualizaciones son relativamente sencillas, pero la mayoría de las veces requieren un significativo y una cantidad de desarrollo que lleva mucho tiempo. Rara vez he visto que este enfoque funcione en la práctica, sobre todo porque con frecuencia implica crear un modelo completamente nuevo.

Posprocesamiento.

Esta es la opción más sencilla de todas y se ha utilizado ampliamente para solucionar problemas de la IA durante décadas. Esto implica cambiar el comportamiento del modelo después de que el sistema haya hecho sus predicciones. Los filtros de salida, por ejemplo, pueden simplemente impedir algunos comportamientos o impedir que se generen predicciones específicas. Por lo general, vienen en forma de 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 de gorilas: su solución consistía en prohibir el sistema desde la identificación de gorilas, incluidas imágenes de gorilas reales.

Lecciones aprendidas

Una vez concluidas las actividades de respuesta, es crucial que las empresas realicen una revisión post mortem para aprender y mejorar de cada incidente. Consiste en dar un paso atrás y evaluar los éxitos y los defectos de la forma en que se abordó el incidente.

Este tipo de revisión implica tomar las siguientes medidas, muchas de las cuales son lo mismo eso debería usarse en las revisiones que se realicen tras la recuperación de los ciberataques a los sistemas de software tradicionales.

• Reúna a los socorristas lo antes posible (quizás unos días después de que termine el incidente) para evaluar el incidente en general.
• Asegúrese de que todas las lecciones aprendidas, tanto las buenas como las malas, se pongan por escrito para que puedan consultarse más adelante. Pensar en qué información debe privilegiarse también es una consideración clave en este proceso.
• Solicite la opinión de un grupo de participantes lo más amplio posible. Si bien los socorristas son fundamentales para la propia respuesta al incidente, otros miembros del personal suelen participar activamente, como abogados, científicos de datos, unidades de negocio y TI.
• Actuar en función de los comentarios. Obviamente, las lecciones aprendidas solo son útiles si se implementan.

Prevenir y responder a los riesgos debe ser un ejercicio continuo. Las buenas formas de seguir preparándose para los incidentes una vez aplicadas las lecciones aprendidas de un incidente incluyen los ejercicios de mesa, los entrenamientos y el trabajo en equipo rojo.

Todas estas actividades pueden parecer complicadas y consumen muchos recursos. He hablado con muchos científicos de datos sobre la respuesta a los incidentes de la IA a los que les preocupa que el tipo de enfoque que he descrito en este artículo pueda retrasar la adopción de la IA. Pero la realidad es la opuesta. En la industria de la automoción se dice con frecuencia que son los frenos, no los motores, los que permiten que los coches vayan rápido. Son los frenos los que dan a los conductores la confianza necesaria para acelerar, porque saben que pueden reducir la velocidad cuando es necesario. Del mismo modo, saber cómo responder cuando las cosas van mal acelerará la adopción de la IA.