Uno de los aspectos más complicados del uso real del aprendizaje automático (ML) en la práctica es relegar la cantidad adecuada de atención al problema de los datos. Esto es algo que discutí en dos columnas anteriores de Dark Reading sobre la seguridad del aprendizaje automático, Integración de la seguridad en el software y Cómo asegurar el aprendizaje automático. 

Verá, la "máquina" en ML en realidad se construye directamente a partir de un montón de datos.

Mis primeras estimaciones del riesgo de seguridad involucrado en el aprendizaje automático afirman con firmeza que los riesgos relacionados con los datos son responsables del 60 % del riesgo general y que el resto de los riesgos (por ejemplo, riesgos de algoritmos o de operaciones en línea) representan el 40 % restante. Me pareció sorprendente y preocupante cuando comencé a trabajar en la seguridad de ML en 2019, principalmente porque no se presta suficiente atención a los riesgos relacionados con los datos. ¿Pero sabes que? Incluso esa estimación se equivocó.

Cuando considera el ciclo de vida completo de ML, los riesgos relacionados con los datos ganan aún más importancia. Esto se debe a que, en términos de exposición pura de datos, a menudo puede ocurrir que poner en práctica ML exponga incluso más datos que entrenar o implementar el modelo de ML en primer lugar. Mucho más. Este es el por qué.

Datos involucrados en el entrenamiento

Recuerde que cuando “entrena” un algoritmo de ML (por ejemplo, cuando utiliza el aprendizaje supervisado para una tarea simple de categorización o predicción), debe pensar detenidamente en los conjuntos de datos que está utilizando. En muchos casos, los datos utilizados para construir el ML en primer lugar provienen de un almacén de datos que almacena datos que son confidenciales para el negocio y conllevan una fuerte carga de privacidad.

Un ejemplo puede ayudar. Considere una aplicación bancaria de ML que ayude a un oficial de crédito a decidir si procede o no con un préstamo. El problema de ML en cuestión es predecir si el solicitante devolverá el préstamo. Usando datos extraídos de préstamos anteriores realizados por la institución, se puede entrenar un sistema ML para hacer esta predicción.

Obviamente, en este ejemplo, los datos del almacén de datos utilizados para entrenar el algoritmo incluyen información estrictamente privada, parte de la cual puede estar protegida (como, por ejemplo, información sobre salarios y empleo, raza y género), así como información comercial confidencial. (como, digamos, si se ofreció un préstamo ya qué tasa de retorno).

El aspecto complicado de seguridad de datos de ML implica el uso de estos datos de manera segura y legal. Reunir y construir los conjuntos de capacitación, prueba y evaluación no es trivial y conlleva cierto riesgo. El campo del modelo ML entrenado también conlleva cierto riesgo, ya que los datos están, en cierto sentido, "integrados" en el modelo ML (y, por lo tanto, están sujetos a fugas, a veces sin querer).

En aras de completar nuestro ejemplo, digamos que el sistema ML que estamos postulando está entrenado dentro del almacén de datos, pero que se opera en la nube y puede ser utilizado por cientos de sucursales regionales y locales de la institución.

Claramente, la exposición de datos es algo en lo que hay que pensar detenidamente cuando se trata de ML.

Datos involucrados en las operaciones

Pero espera hay mas. Cuando se implementa un sistema ML como el que estamos discutiendo, funciona de la siguiente manera. Las nuevas situaciones se recopilan y se integran en "consultas" usando el mismo tipo de representación que se usó para construir el modelo ML en primer lugar. Esas consultas luego se presentan al modelo que las usa como entradas para devolver una predicción o categorización relevante para la tarea en cuestión. (Esto es lo que la gente de ML quiere decir cuando dicen predicción autoasociativa).

Volviendo a nuestro ejemplo de préstamo, cuando llega una solicitud de préstamo a través de un oficial de préstamo en una sucursal, parte de esa información se utilizará para crear y ejecutar una consulta a través del modelo ML como parte del proceso de toma de decisiones de préstamo. En nuestro ejemplo, es probable que esta consulta incluya tanto información comercial confidencial como privada protegida sujeta a control regulatorio.

Es muy probable que la institución haga un buen uso del sistema ML entre cientos de miles (o tal vez incluso millones) de clientes que buscan préstamos. Ahora piense en el riesgo de exposición de datos que conllevan las propias consultas compuestas. Esa es una gran pila de datos. Algunos analistas estiman que el 95 % de la exposición de datos de ML proviene de la exposición operativa de este tipo. Independientemente del desglose real, está muy claro que la exposición de datos operativos es algo en lo que hay que pensar detenidamente.

Limitación de la exposición de datos

¿Cómo se puede mitigar adecuadamente este riesgo de exposición de datos operativos integrado en el uso de ML?

hay muchas maneras de hacer esto. Uno podría cifrar las consultas en su camino hacia el sistema ML y luego descifrarlas solo cuando se ejecutan a través del ML. Dependiendo de dónde se ejecute el sistema ML y quién lo esté ejecutando, eso puede funcionar. Como ejemplo, el sistema BigQuery de Google admite claves administradas por el cliente para hacer este tipo de cosas.

Otra solución más inteligente puede ser transformar estocásticamente la representación de los campos de consulta, minimizando así la exposición de la información original al proceso de decisión del ML sin afectar su precisión. Esto implica cierta comprensión de cómo el ML toma sus decisiones, pero en muchos casos se puede utilizar para reducir significativamente las consultas (ocultar campos que no son relevantes). Protopia AI persigue este enfoque técnico junto con otras soluciones que abordan el riesgo de datos de ML durante el entrenamiento. (Divulgación completa, soy asesor técnico de Protopia AI).

Independientemente de la solución particular, y para mi sorpresa, el riesgo de exposición de datos operativos en ML va mucho más allá del riesgo de presentar un modelo con los datos de entrenamiento "incorporados". El riesgo de exposición de datos operativos es una cosa, y algo que se debe observar de cerca, a medida que madura la seguridad de ML.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://www.darkreading.com/risk/irresponsible-ai-training-the-data-elephant-in-the-room