Si hay una constante en el mundo de la tecnolog\u00eda, es que cuanto m\u00e1s se adopta una tecnolog\u00eda, m\u00e1s falla. Este art\u00edculo trata sobre qu\u00e9 hacer ante incidentes de IA y c\u00f3mo responder cuando ocurren.\u00a0 Gran parte de este art\u00edculo se basa en la investigaci\u00f3n que la firma Luminos.Law realiz\u00f3 para el Instituto Nacional de Est\u00e1ndares y Tecnolog\u00eda, as\u00ed como en los conocimientos adquiridos en nuestro trabajo, centrado exclusivamente en la gesti\u00f3n de responsabilidades relacionadas con la IA. A lo largo del art\u00edculo se referir\u00e1 a algunos incidentes espec\u00edficos, pero cada uno de ellos se ha anonimizado para proteger la confidencialidad del cliente.<\/p>\n
La respuesta a incidentes para sistemas de software tradicionales (programados con miles o millones de l\u00edneas de c\u00f3digo) se ha consolidado en las \u00faltimas dos d\u00e9cadas. Existe\u00a0un manual de estrategias ampliamente aceptado\u00a0para la respuesta a incidentes tradicionales. Sin embargo, no existe un manual similar para incidentes de IA. Hace casi una d\u00e9cada, por ejemplo, Google cre\u00f3 una herramienta de IA que etiquetaba autom\u00e1ticamente objetos en im\u00e1genes, solo para descubrir que\u00a0etiquetaba sistem\u00e1ticamente a las personas negras como gorilas. Los marcos de respuesta a incidentes para sistemas de software tradicionales no habr\u00edan sido de mucha ayuda para responder a este tipo de incidente de IA.<\/p>\n
De hecho, ni siquiera la definici\u00f3n tradicional de \u00abincidente\u00bb para sistemas de software se aplicaba directamente a la IA. As\u00ed, por ejemplo, el NIST\u00a0define\u00a0un incidente en el contexto tradicional de la ciberseguridad:<\/p>\n
\nCualquier suceso que (1) ponga en peligro real o inminentemente, sin autorizaci\u00f3n legal, la integridad, confidencialidad o disponibilidad de la informaci\u00f3n o de un sistema de informaci\u00f3n; o (2) constituya una violaci\u00f3n o amenaza inminente de violaci\u00f3n de la ley, de las pol\u00edticas de seguridad, de los procedimientos de seguridad o de las pol\u00edticas de uso aceptable.<\/p>\n<\/blockquote>\n
Esta definici\u00f3n se basa principalmente en la idea de que los incidentes son causados \u200b\u200bpor actores maliciosos que realizan acciones indebidas. Si bien estos actores pueden usar la IA para causar da\u00f1os o atacar los propios sistemas de IA, estos generan nuevos tipos de da\u00f1os 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, \u00bfpor d\u00f3nde deber\u00edan empezar las organizaciones al prepararse para incidentes de IA? La respuesta est\u00e1 en las pol\u00edticas de respuesta a incidentes.<\/p>\n
<\/h2>\n
Preparaci\u00f3n para la respuesta a incidentes de IA<\/strong><\/h2>\n
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\u00edticas y procedimientos propios para guiar a las empresas y al personal involucrado en la respuesta. Las pol\u00edticas de respuesta a incidentes con IA deben abordar los siguientes aspectos.<\/p>\n
Crear una definici\u00f3n de IA.<\/strong><\/h3>\n
Esto podr\u00eda parecer obvio en una pol\u00edtica de respuesta a incidentes, pero muchas empresas han adoptado sistemas de IA y creado pol\u00edticas 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\u00e1ndose en su capacidad para detectar patrones en los datos, lo cual coincide con la mayor\u00eda de las definiciones de sistemas modernos de IA o aprendizaje autom\u00e1tico. Esto significa que, en la pr\u00e1ctica, los modelos que no aprenden de los datos, como los sistemas tradicionales basados \u200b\u200ben reglas, no deber\u00edan estar contemplados en las definiciones de IA.<\/p>\n
M\u00e1s importante a\u00fan, muchas empresas no definen claramente qu\u00e9\u00a0no es<\/em> la IA, lo que puede dificultar saber cu\u00e1ndo confiar en pol\u00edticas de respuesta a incidentes de IA frente a pol\u00edticas y equipos de respuesta a incidentes m\u00e1s tradicionales. Para complicar a\u00fan m\u00e1s la situaci\u00f3n, 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\u00e1s grande. Saber d\u00f3nde termina el sistema de software tradicional y d\u00f3nde comienza el chatbot es fundamental.<\/p>\n
Identificar los da\u00f1os m\u00e1s relevantes.<\/strong><\/h3>\n
Para algunas organizaciones, como las dedicadas a la rob\u00f3tica o el transporte, los da\u00f1os f\u00edsicos podr\u00edan ser los m\u00e1s relevantes. Otros da\u00f1os importantes podr\u00edan estar relacionados con oportunidades econ\u00f3micas o cuestiones de equidad, algo que mi firma suele priorizar entre los clientes de servicios financieros y atenci\u00f3n m\u00e9dica. La lista de posibles da\u00f1os es larga y debe considerarse cuidadosamente al elaborar pol\u00edticas y planificar la composici\u00f3n de los equipos de respuesta a incidentes.<\/p>\n
Designar personas que respondan ante incidentes.<\/strong><\/h3>\n
Organizaciones como el Instituto de Pol\u00edtica y Estrategia de IA\u00a0recomiendan\u00a0personal con una combinaci\u00f3n de experiencia, como TI, ciberseguridad, comunicaciones, derecho, unidades de negocio y expertos en el sector. Tambi\u00e9n 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 \u00fatil cuando las empresas no cuentan con los recursos internos necesarios para responder plenamente a sus propios incidentes de IA.<\/p>\n
Desarrollar un plan de contenci\u00f3n a corto plazo.<\/strong><\/h3>\n
Una vez establecidas las pol\u00edticas de respuesta a incidentes, la siguiente y m\u00e1s 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\u00f3mo contener el incidente a corto plazo mientras se desarrollan estrategias de respuesta a largo plazo. El plan debe estar listo antes de la implementaci\u00f3n efectiva de un modelo.<\/p>\n
Estos planes consisten en instrucciones generales sobre c\u00f3mo modificar los sistemas de IA una vez implementados para mitigar los da\u00f1os que cualquier incidente pueda causar. Tambi\u00e9n 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\u00faan con la IA.<\/p>\n
Comprender c\u00f3mo y por qu\u00e9 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\u00eda un plan similar cuando descubri\u00f3 que una herramienta de selecci\u00f3n de RR. HH. basada en IA, utilizada para evaluar a los solicitantes de empleo, estaba dando un trato preferencial a un grupo demogr\u00e1fico espec\u00edfico. Como resultado, sus l\u00edderes se encontraron en un punto muerto: pod\u00edan seguir usando la herramienta y permitir que los da\u00f1os persistieran, o pod\u00edan desactivarla. Al final, optaron por desactivar el sistema de IA, que permaneci\u00f3 fuera de servicio durante m\u00e1s de un a\u00f1o. Si hubieran tenido un plan de contenci\u00f3n a corto plazo, podr\u00edan haber reducido el uso de la herramienta o modificarla para comprender el origen del incidente y todas las opciones para contenerlo.<\/p>\n
<\/h2>\n
Identificaci\u00f3n r\u00e1pida de incidentes<\/strong><\/h2>\n
Identificar incidentes r\u00e1pidamente puede ser complicado. Como se mencion\u00f3 anteriormente, los actores maliciosos no siempre son la causa; los sistemas de IA son probabil\u00edsticos, lo que significa que se garantiza que se equivocar\u00e1n y realizar\u00e1n 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\u00fan m\u00e9todo de detecci\u00f3n es infalible, existen diversas herramientas y enfoques que pueden ayudar a identificar incidentes de IA en la pr\u00e1ctica. El primero, llamado\u00a0\u00abapelaci\u00f3n y anulaci\u00f3n\u00bb,\u00a0es una funcionalidad que, como\u00a0la describe el NIST, permite a los usuarios \u00abutilizar canales f\u00e1ciles de usar, como formularios de comentarios, correos electr\u00f3nicos o l\u00edneas directas… para informar problemas, inquietudes\u00bb o \u00abresultados no deseados para incorporarlos a las pr\u00e1cticas de monitoreo\u00bb.<\/p>\n
Dar a los usuarios la capacidad de marcar comportamientos inapropiados o indeseables del sistema permite que aquellos que m\u00e1s interact\u00faan con el sistema cumplan una funci\u00f3n de alerta.<\/p>\n
Adem\u00e1s de las capacidades de apelaci\u00f3n y anulaci\u00f3n, las empresas tambi\u00e9n pueden utilizar sistemas de monitoreo de modelos y configurar alertas para comportamientos an\u00f3malos o problem\u00e1ticos. Las directrices emitidas por los gobiernos de Canad\u00e1, el Reino Unido, Australia y Estados Unidos a principios de este a\u00f1o\u00a0exigieron\u00a0espec\u00edficamente este tipo de monitoreo para garantizar la seguridad de la IA.<\/p>\n
Por \u00faltimo, las pruebas realizadas por partes internas o externas, idealmente, incluso antes de la implementaci\u00f3n del sistema de IA, pueden revelar problemas. Un enfoque similar es el\u00a0\u00abequipo rojo\u00bb,\u00a0en el que un grupo independiente de los cient\u00edficos de datos que desarrollaron el sistema intenta atacarlo o provocar que haga algo perjudicial.<\/p>\n
<\/h2>\n
Qu\u00e9 hacer tras identificar un incidente de IA: contenci\u00f3n, erradicaci\u00f3n y recuperaci\u00f3n<\/strong><\/h2>\n
Una vez identificados los incidentes, el siguiente paso es implementar una estrategia de contenci\u00f3n a largo plazo para evitar que el da\u00f1o se propague a\u00fan m\u00e1s. Estas son las preguntas clave que dicha evaluaci\u00f3n deber\u00eda responder:<\/p>\n
\u00bfQui\u00e9n est\u00e1 siendo perjudicado?<\/strong><\/h3>\n
Dado que la definici\u00f3n de un incidente de IA se centra en los da\u00f1os reales o potenciales, comprender qui\u00e9n est\u00e1 siendo perjudicado y en qu\u00e9 medida se producen es una de las primeras preguntas que las empresas deben responder. Poco despu\u00e9s de implementar un sistema de IA generativa, un cliente descubri\u00f3 que el sistema se hab\u00eda entrenado con grandes cantidades de datos problem\u00e1ticos, incluyendo materiales con derechos de autor y datos personales recopilados sin el consentimiento de los usuarios. En este caso, un cient\u00edfico de datos interno detect\u00f3 el error despu\u00e9s de implementar el modelo, algo muy com\u00fan cuando los equipos legales no participan en las primeras etapas del desarrollo del modelo. La empresa necesitaba comprender r\u00e1pidamente de qui\u00e9n eran los datos que se hab\u00edan incorporado al sistema de IA y qu\u00e9 leyes aplicaban.<\/p>\n
\u00bfCu\u00e1les son las opciones para modificar el comportamiento del sistema de IA?<\/strong><\/h3>\n
Si las empresas tienen suerte, puede haber varias opciones para cambiar el comportamiento del sistema de forma r\u00e1pida y fiable, especialmente si la IA no tiene numerosas dependencias, tanto ascendentes como descendentes. El Instituto de Pol\u00edtica y Estrategia de IA (IA) elabor\u00f3\u00a0\u200b\u200buna taxonom\u00eda espec\u00edfica\u00a0para este tipo de opciones, que abarca desde restringir cada sistema de IA a un conjunto espec\u00edfico 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\u00e1ticos, como el sistema de IA generativa de nuestro cliente, algunos m\u00e9todos de vanguardia\u00a0pueden ense\u00f1ar\u00a0al modelo a \u00abdesaprender\u00bb aquello con lo que fue entrenado.<\/p>\n
\u00bfQu\u00e9 est\u00e1 causando el da\u00f1o?<\/strong><\/h3>\n
Detectar y erradicar a los actores maliciosos suele ser m\u00e1s 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\u00f3mo surgi\u00f3 el da\u00f1o (de los atacantes, los datos de entrenamiento, la arquitectura del modelo, etc.) es importante para las siguientes fases de la respuesta a incidentes.<\/p>\n
\u00bfEs posible abordar o rectificar de alg\u00fan modo los da\u00f1os existentes?<\/strong><\/h3>\n
Una vez ocurrido el incidente, es importante no solo comprender qui\u00e9nes se han visto perjudicados, sino tambi\u00e9n qu\u00e9 pueden hacer las empresas al respecto. Un tipo com\u00fan de incidente surge cuando se ofrecen servicios preferenciales, como descuentos en productos, solo a grupos demogr\u00e1ficos espec\u00edficos.<\/p>\n
Una vez implementados y ejecutados los planes de contenci\u00f3n, 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\u00f3n, pero otros solo permiten una erradicaci\u00f3n parcial o incluso no pueden eliminar la fuente del incidente. A grandes rasgos, existen\u00a0tres maneras principales\u00a0de abordar o corregir el comportamiento problem\u00e1tico de los modelos, cada una de las cuales se ha\u00a0utilizado durante mucho tiempo\u00a0para depurar modelos de aprendizaje autom\u00e1tico:<\/p>\n
\n
- \n
\n
- Preprocesamiento.<\/strong><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Esto se relaciona con\u00a0las acciones que se pueden realizar\u00a0antes 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\u00e1tico del modelo. En ese caso, la soluci\u00f3n es volver a entrenar el modelo con datos de entrenamiento m\u00e1s representativos.<\/p>\n
\n
- \n
\n
- En procesamiento.<\/strong><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Este tipo de correcciones implican cambiar los pesos o la arquitectura del propio modelo. A veces, estas actualizaciones son relativamente sencillas, pero la mayor\u00eda de las veces requieren un desarrollo\u00a0considerable\u00a0y laborioso. Rara vez he visto que este enfoque funcione en la pr\u00e1ctica, principalmente porque suele implicar la creaci\u00f3n de un modelo completamente nuevo.<\/p>\n
\n
- \n
\n
- Postprocesamiento.<\/strong><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Esta es la opci\u00f3n m\u00e1s sencilla y se ha utilizado ampliamente para solucionar problemas de IA\u00a0durante d\u00e9cadas\u00a0. Implica cambiar el comportamiento del modelo despu\u00e9s de que el sistema haya realizado sus predicciones. Los filtros de salida, por ejemplo, pueden simplemente deshabilitar alg\u00fan comportamiento o impedir que se generen predicciones espec\u00edficas. Estos suelen consistir en reglas que se pueden a\u00f1adir al modelo. Esa fue la soluci\u00f3n que Google implement\u00f3 para abordar la herramienta de IA que etiquetaba a los negros como gorilas: su soluci\u00f3n fue\u00a0prohibir\u00a0que el sistema identificara gorilas, incluidas fotos de gorilas reales.<\/p>\n
<\/h2>\n
Lecciones aprendidas<\/strong><\/h2>\n
Tras finalizar las actividades de respuesta, es fundamental que las empresas realicen una revisi\u00f3n post mortem para aprender y mejorar de cada incidente. Esta consiste en analizar en perspectiva los aciertos y errores de la gesti\u00f3n del incidente.<\/p>\n
Este tipo de revisi\u00f3n implica tomar las siguientes acciones, muchas de las cuales son\u00a0las mismas\u00a0que se deben utilizar en las revisiones realizadas despu\u00e9s de la recuperaci\u00f3n de los ciberataques a los sistemas de software tradicionales.<\/p>\n
\n
- Convoque a los equipos de respuesta al incidente lo m\u00e1s r\u00e1pidamente posible (quiz\u00e1s unos pocos d\u00edas despu\u00e9s de que concluya el incidente) para evaluar el incidente en general.<\/li>\n
- Aseg\u00farese de que todas las lecciones aprendidas, tanto las positivas como las negativas, queden por escrito para que puedan consultarse posteriormente. Pensar en qu\u00e9 informaci\u00f3n debe ser privilegiada tambi\u00e9n es un factor clave en este proceso.<\/li>\n
- Solicite la retroalimentaci\u00f3n del grupo m\u00e1s 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\u00edficos de datos, unidades de negocio y TI.<\/li>\n
- Act\u00fae seg\u00fan la retroalimentaci\u00f3n. Obviamente, las lecciones aprendidas solo son \u00fatiles si se implementan.<\/li>\n<\/ul>\n
La prevenci\u00f3n y la respuesta a los riesgos deben ser una actividad continua. Una vez implementadas las lecciones aprendidas, se recomiendan ejercicios de simulaci\u00f3n, capacitaciones y la formaci\u00f3n de equipos de respuesta.<\/p>\n
\nTodas estas actividades pueden parecer complicadas y consumir muchos recursos. He hablado con muchos cient\u00edficos de datos sobre la respuesta a incidentes de IA, quienes temen que el tipo de enfoque que he descrito en este art\u00edculo pueda ralentizar la adopci\u00f3n 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\u00e1pido. 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\u00f3mo responder cuando las cosas salen mal es lo que acelerar\u00e1 la adopci\u00f3n de la IA<\/em>. Andrew Burt\u00a0es cofundador de\u00a0Luminos.Law<\/span><\/p>\n<\/blockquote>\n
<\/p>\n
\n