Sistemas de Streaming, Riesgos Ocultos y Consecuencias impulsadas por IA

Estoy muy agradecido de estar aquí. Me encanta Londres. Tanta historia. Y sobre el tema de la historia, en realidad quería preguntarles, ¿alguno de ustedes ha oído o sabe quién es el Mayor William Martin? Nadie. No hay sorpresas ahí. Es una historia antigua.

También una triste. Así que estamos de vuelta en 1943. Europa está en guerra y los Aliados están preparando el próximo gran movimiento en el Mediterráneo. Y en algún lugar del mar, un soldado británico nunca llega a casa. Así que un joven es encontrado en la costa de la frontera española al sur. Y lleva consigo un maletín con algunos documentos. Así es como conocemos su nombre. También sabemos que tiene una prometida, Pam. También sabemos que es bastante malo con el dinero porque tiene algunas cartas del banco con sobregiro.

Tiene algunos de los recibos de pago comprando un anillo de compromiso. Así que tiene todo un futuro por delante, que nunca sucedió. También en ese maletín, hay algo más interesante, algo mucho más valioso para las autoridades españolas. Es una carta entre los tenientes hablando sobre los próximos planes de los Aliados para atacar Cerdeña y Grecia. Así que esas cartas encuentran el camino hacia la inteligencia alemana. Y ahora la inteligencia alemana tiene la información para hacer su movimiento, sabiendo lo que los Aliados han planeado.

Esto juega un papel bastante importante en el desarrollo de la guerra y cómo los alemanes redistribuirán sus fuerzas para sacar las fuerzas de Sicilia y llevarlas a defender Grecia y Cerdeña. La única pequeña cosa es que el Mayor William Martin en realidad nunca existió. Este es uno de los ejemplos históricos interesantes de envenenamiento de la información. Y toda la operación es muy interesante en sí misma. Hay una película, hay mucho que leer al respecto. Pero la idea completa es que envenenamos el sistema de toma de decisiones, y aquí fue la inteligencia alemana, al traer algo que es factible, que es muy auténtico y puede ser confiado.

Y una vez que los alemanes confiaron en esa pieza de información, tomaron una decisión equivocada totalmente por sí mismos. No hubo necesidad de ir y, no sé, afectar todo el sistema de redes, o ir y atacar su cuartel general. Toda la confusión proviene de la información muy sutil que llegó a manos de la inteligencia alemana.

Y si estás interesado, deberías leerlo, porque pusieron mucho esfuerzo en hacer que ese Mayor en particular fuera creíble, desde la tinta que se usó para escribir las cartas, hasta la ropa interior que llevaba ese cadáver, hasta la temperatura, cómo se debe preservar el cuerpo en el agua, en el mar, hasta la ubicación donde se debe encontrar el cuerpo. Todo fue pensado muy, muy a fondo. Pero la idea completa que quería compartir hoy es que con la IA, que depende mucho de la información de la que se alimenta, tenemos eventos, tenemos registros, tenemos indicaciones de transacciones, todo lo demás. Y si la entrada está envenenada, el modelo a menudo es totalmente operativo, totalmente válido. Toma la decisión correcta basada en la información proporcionada. Y la decisión es completamente incorrecta, porque la entrada fue envenenada intencional o involuntariamente. Y proviene de diferentes ángulos.

El primero es entrenar y refinar el modelo. Y no estoy seguro de cuántos de ustedes aquí han entrenado el modelo desde cero para sus aplicaciones. No veo ninguna mano levantada. ¿Cuántos de ustedes han refinado modelos existentes? Hay algunas personas asintiendo con la cabeza. Tenemos algunas personas que han refinado los modelos. Entonces, si haces cualquiera de esos pasos, necesitas saber que en realidad es bastante posible envenenar y crear una puerta trasera en el modelo. Y Antropic, junto con el Alan Turing Institute y otros, en realidad examinaron los modelos que van desde 600 millones hasta 13 mil millones de parámetros. ¿Y puedes adivinar cuántos documentos se necesitaron para crear la puerta trasera? ¿Alguna suposición? Puedes decirlo en voz alta. Uno. ¿Uno? Oh, está bien. Más de uno, afortunadamente. Entonces, fueron 250. Y hay un documento completo, y dicen que ese número, 250, se mantiene constante independientemente del tamaño del modelo.

Así que, más o menos, 250 documentos maliciosos, y tu modelo, o el modelo, puede simplemente hacer "quack". Puedes activar esta frase en particular, un comportamiento muy diferente del modelo. Así que eso es sobre el entrenamiento y refinamiento. Pero en lo que quería centrarme hoy es en algo un poco más aplicable. Entonces, la inferencia, algo que hacemos a diario. Y ahí es donde combinamos el prompt, el contexto, y luego usamos una serie de diferentes fuentes, que van desde las herramientas que provienen del MCP, algunos almacenamientos de datos como Postgres, usamos Data Lakes, donde en Confluent, también confiamos mucho en Kafka y Flink para transmitir los eventos en tiempo real, como, por ejemplo, transacciones, transacciones bancarias, y así sucesivamente. Así que, todos los datos van al modelo, y el modelo nos da una respuesta. Y ahora, con toda esa cantidad de datos mezclados y combinados, es un lugar increíble para poner algo de química, como química y cosas venenosas. Así que, un documento bastante reciente, la colaboración con DigitalOcean y la Universidad Estatal de Arizona, en realidad examinaron los registros. Así que, el modelo estaba ingiriendo registros y alertas para clasificar los incidentes, resumir la actividad, y recomendar remediaciones para los incidentes de seguridad. Y mostraron que los registros, porque los registros son en gran medida texto base, y es un tipo de control del atacante.

Entonces, tenemos los agentes de usuario, tenemos URLs, tenemos cargas útiles, consultas DNS, nombres de usuario intentados. Así que, toda esa información basada en texto es posible formatear y presentar de manera que introduzca entradas venenosas. Y muestran que si no haces ninguna protección, el 96% de los ataques de ingestión que ejecutaron, en realidad pasaron con éxito. Si haces más control, como intentar limitar la salida e intentar de alguna manera darle forma y prevenirlo, el 38% de los ataques aún fueron exitosos.

Luego, otro artículo reciente interesante, Oracle Poisoning, donde en realidad intentaron atacar usando paquetes falsos, las inyecciones SQL, bibliotecas maliciosas, y simplemente manipulan el mundo en el que vive el modelo. Así que, no atacan el modelo en sí, solo atacan toda esa información que está alrededor del modelo. Y hay muchas cosas interesantes que salen de este artículo, entre las cuales, por ejemplo, que el modo de entrega de esa información venenosa realmente importa.

Así que, hablamos mucho sobre las inyecciones de prompt, y la cuestión es que, si solo inyectas esa información venenosa o información inválida a través del prompt, los modelos ya no confían tanto en ella. Son más escépticos. Así que, tenemos una pequeña victoria en esa área. Entonces, mostraron que, está bien, esta inyección en línea, los modelos creen 0%. Pero, si tienes la misma información maliciosa falsa a través del uso de herramientas, a través del uso real de herramientas donde el modelo recupera esa información de alguien, el modelo confía en ella al 100%.

Entonces, el modo de entrega importa mucho, y luego analizan la mitigación, afirmando que la visibilidad, la comprensión y la trazabilidad de los datos son los aspectos más importantes de cómo podemos prevenir esos ataques.

Así que, los datos se convierten en la superficie de ataque para nosotros, y si miramos el pipeline en tiempo real que depende del machine learning o LLMs en un estado muy simple, será la fuente de datos que entra en algún tipo de sistema de streaming. Estoy usando Apache Kafka, sé que es el mejor. Al enriquecer esa información, recuperamos aquellas características que necesitamos para el modelo de machine learning o para LLM, y luego llevamos esta información a un LLM y tenemos un impacto comercial a partir de la salida del LLM.

Así que, si tomamos, por ejemplo, el sistema de detección de fraude en tiempo real, que ya existía desde hace un tiempo, incluso antes de los LLMs, entonces tenemos algún tipo de aplicación que producirá una transacción. La transacción entrará en el streaming de datos. También obtendremos información adicional, o trabajaremos con los datos, tomando algunos fragmentos, para que entre en algún tema enriquecido, y luego usamos esos datos junto con el modelo de fraude, y decidiremos si aprobar, rechazar, o tal vez examinar esa transacción en particular.

Y puedes imaginar que esto realmente tiene que funcionar en tiempo real muy rápido con grandes volúmenes de datos. Entonces, si eres una persona malintencionada que quiere romper este sistema de detección de fraude, o conseguir algo de dinero extra para tu cuenta bancaria, puedes, por supuesto, intentar atacar el modelo directamente, pero no tienes que hacerlo. De hecho, puedes simplemente influir en el flujo de eventos ascendente. Así que, puedes inyectar o manipular eventos que hagan que una cuenta comprometida parezca totalmente normal. Y lo harás con pequeñas transacciones benignas que se transmiten con el tiempo. Así que, te tomarás tu tiempo para enviar algunos eventos de huella digital de dispositivos, eventos de inicio de sesión, y para cuando el atacante realmente envíe la transacción fraudulenta real, la cuenta estará configurada para ser considerada de bajo riesgo, y esa transacción en particular será una transacción de bajo riesgo.

Así que, la misma situación ocurre con la recomendación, manipulación de salida, telemetría de seguridad, agentes de infraestructura de IA, que decidirán escalar o desescalar. Así que, hay muchas variaciones diferentes donde los ataques de repetición hacen que los eventos históricos vuelvan a pasar por el sistema para convencer de que el patrón es correcto. Y la complejidad surge porque no es realmente súper lineal. Usualmente tenemos un número numeroso de fuentes. Tenemos una gran cantidad de flujos, como esos temas de Kafka que suelo ver, o no usualmente, pero a menudo veo los proyectos reales donde tienen 1,000 de esos temas, y no tengo idea de cómo se navegan. Pero todo el sistema es bastante complejo. Así que, en realidad es toda una red de información que pasa por el sistema y donde estamos tratando de dar sentido a esa información. Y la clave aquí es si logramos entender dónde exactamente, como exactamente la información está navegando y qué está sucediendo dónde.

Así que, un par de ideas aquí, lo que es importante basado en la experiencia incluso antes de los LLMs, es la primera saber quién puede hablar con tu sistema o a quién realmente escuchamos. Y antes de que cualquier aplicación pueda actuar sobre el flujo de esa información entrante, debe alcanzar la red, debe presentar una identidad, autenticarse y pasar las verificaciones de autorización. Así que, por ejemplo, podemos controlar la red. Podemos controlarla para reducir la exposición para esa entrada particular y para nuestra infraestructura de streaming sensible. Así que, esto no previene el envenenamiento, todo el envenenamiento, especialmente si los datos comprometidos ya son internos, pero reducirá quién puede realmente incluso alcanzar el plano de datos. Así que, entonces es bastante importante también identificar quién eres. ¿Puedes probarlo, quién eres, y también qué exactamente puedes hacer? O aquí, no es exactamente que si tienes derecho a escribir en el tema, pero la pregunta es, ¿tienes autoridad para afirmar ese hecho, que luego usamos para nuestro modelo de decisión? Lo siguiente es la forma y calidad de los datos. Así que, aquí estamos hablando de un esquema y todo, muchos sistemas de IA, consumen datos provenientes de diferentes fuentes. Y la forma de los datos que llegan es normal que cambie. Su lógica de negocio cambia, por lo que los datos estarán en diferente forma. Pero si la forma cambia inesperadamente, el modelo puede recibir información faltante, mal informada, o características engañosas. Y si el evento estructuralmente es inválido, puede llevar a rupturas accidentales, pero también puede ser una entrada maliciosa de bajo esfuerzo, que realmente intenta confundir el modelo. Por supuesto, un evento falso aún puede ser perfectamente válido según el esquema. Así que, tiene restricciones. Y para mejorar eso, a menudo hablamos de contratos de datos. Así que, los contratos de datos, no es solo, por ejemplo, el esquema dirá, este campo debe existir, y debe ser un número.

Un contrato de datos dirá que debe estar dentro del rango aceptable, seguir una regla de negocio, y debe ser tratado como sensible. Así que, el control de datos va más allá de la forma básica del esquema. Establece expectativas de calidad, añadimos algo de metadatos allí, para que sepamos qué reglas de transformación se aplican a ese registro, y podemos hacer cumplir esas restricciones, podemos validar valores de campo, etiquetar datos sensibles, y eleva el estándar de un campo, o como un valor, que es un evento bien formado, a un evento bien formado y también consciente de políticas. Y esto es bastante importante para cualquier canalización, incluidas las canalizaciones de IA, para tener esta mejor calidad de datos y expectativas semánticas en eso.

Y eso nos ayudará también a entender qué hacemos con esos datos cuando llegan. ¿Debería ser descartado? ¿Deberíamos, no sé, como poner retrasos para que podamos decidir qué hacer con ello? Además, qué propiedades, por ejemplo, son sensibles, que necesitan tener acción extra, ya sea para ser cifradas, o, por ejemplo, si los datos luego van a entrenar el modelo, ¿queremos realmente eliminar totalmente el campo PII para que no participen en ese entrenamiento del modelo y los datos del cliente no se filtren?

Y también los contratos de datos, juegan un papel importante para la gobernanza de flujos, y la gobernanza de flujos es una parte bastante importante en general cuando hablamos de sistemas de transmisión de datos. Por ejemplo, los sistemas de IA, a menudo consumen características, estado, contexto, o resultados de salida sin saber lo suficiente de dónde provienen realmente los datos. Y cuando hablamos de los sistemas de transmisión, es una cosa saber que tenemos los datos fluyendo a través del sistema de transmisión de datos.

Así que aquí usualmente hablamos de dos conceptos. El catálogo de flujos es donde sabemos qué flujos tenemos, qué flujos de datos tenemos dentro del sistema. Y también el linaje de flujo, esto es donde, cómo los datos se mueven a través del sistema, de dónde vienen y a dónde van. Y, por ejemplo, si un modelo de fraude aprueba una transacción sospechosa sin el linaje, podríamos solo obtener información de que un modelo usó una puntuación de bajo riesgo. Pero con el linaje, podremos preguntar, de dónde vino esa puntuación de bajo riesgo, y qué tema llevó esa información sobre la reputación del dispositivo, qué trabajo de enriquecimiento realmente une esas características, y tal vez hubo alguna actividad inusual del productor, que consumió información inicial. Así que esto es bastante importante también para rastrear qué está sucediendo y por qué obtenemos ese resultado.

Y lo último, que es bastante importante, es poder detectar y responder a esas cosas en tiempo real. Así que usamos métricas, usamos registros de auditoría, y también para el procesamiento de flujos, a menudo usamos detección de anomalías. De hecho, para la detección de anomalías, como en la consola, realmente no confiamos en LLMs, es demasiado lento, pero confiamos en modelos de machine learning o en modelos matemáticos estadísticos porque son mucho más rápidos y más predecibles. Y sí, así que obtenemos esa información y convertimos la detección en respuesta. Así que, sí, necesitamos asegurar, gobernar, validar nuestros datos y recordar, por ejemplo, para este caso, que debemos controlar quién puede escribir, validar cuál es el rastro correcto, de dónde vienen los datos, y prevenir que la IA actúe a ciegas en sus flujos de baja confianza.

Así que eso es lo que quería compartir con ustedes hoy, así que con suerte tendremos menos envenenamiento, incluyendo de la IA. Increíble, muchas gracias, Olena. Un aplauso, gracias. Fantástico. Solo para, supongo, decirlo una vez más, pueden enviar sus preguntas a través de Slido. El enlace, el código es 0607. Comencemos con la primera pregunta que tenemos allí. ¿Prevés que el envenenamiento empeore en una era de IA auto-mejorada? Creo que sí, porque es una puerta fácil. Tenemos muchos problemas con la seguridad en general. Como hay, cuando se trata de IA, no faltan historias interesantes donde la seguridad compromete las violaciones de datos, tenemos como cada dos días, las mayores violaciones de datos, y en dos semanas tenemos otra, aún mayor. Y es mucho dinero. Así que es como el dinero motiva a las personas a hacer cosas interesantes. Y el envenenamiento de datos es algo bastante interesante. Así que tristemente, no veo que se detenga pronto. Increíble, fantástico, muchas gracias. La otra pregunta que tengo aquí es, ¿qué estrategias has encontrado efectivas para detectar la degradación silenciosa del rendimiento? ¿En flujos aumentados por IA? Así que esto, sí, así que creo que las métricas y la observación, así que como detectar anomalías, lo que estaba mencionando, como por ejemplo, esos números, cuando tenemos cuánto tiempo toma, por ejemplo, para que los datos sean procesados, ¿hay algún retraso extraño en particular? Esos deberían ser capturados durante esta etapa donde estás mirando las métricas o estás mirando el resultado de las detecciones de anomalías. Y sí, por ejemplo, estamos usando esta detección de anomalías bastante para ver como una desviación de la información que llega en diferentes casos de uso. Como si miras, por ejemplo, los métodos de pago, también estamos usando detección de anomalías allí. Pero creo que es todo junto con las métricas y los registros de auditoría para entender porque entonces ves esa desviación, pero necesitas entender de dónde viene.

Así que tienes que ir un poco río arriba para entender de dónde viene. Sí. Fantástico, muchas gracias.

El siguiente aquí es, parece que el envenenamiento es inevitable. Has mencionado varias formas de aplicar la observabilidad a los resultados o el comportamiento. ¿Has visto alguna forma o manera dirigida de detectar datos incorrectos temprano? Los datos incorrectos dependen de lo que estamos hablando. Aquí dice, desplazar a la izquierda la detección. Sí, así que necesitas detectarlo antes. Todavía aplicaría lo mismo. Así que creo que necesitas detectarlo lo más rápido posible y supongo que el flujo es usualmente muy, muy complejo. Así que si puedes realmente entender que el problema está surgiendo antes en el flujo, entonces proteges el otro lado del flujo. Increíble, fantástico.

El siguiente es, si un sistema de IA se entrena continuamente con datos recién recopilados, ¿cómo decidirías cuándo los nuevos datos son lo suficientemente confiables para incluirlos en el entrenamiento? Así que usualmente, y para ser honesto, estoy lejos de entrenar los modelos desde cero. Pero como lo veo es que los modelos no se entrenan con un solo dato. De hecho, los entrenamos con un lote de registros. Así que el entrenamiento es un poco diferente a la inferencia porque aquí recopilamos los datos y luego comenzamos a entrenar el modelo. Tal vez los ciclos ahora son mucho, mucho más cortos, pero aún así mis puntos eran principalmente sobre la inferencia. Pero si estás hablando sobre el entrenamiento del modelo con los datos recopilados, por supuesto, los datos recopilados también son un flujo. También deberías verificarlo y validarlo y entender de dónde viene para poder asegurarte de que no lo estás entrenando en algún tipo de fuente sospechosamente poco confiable. Increíble, fantástico.

Muchas gracias, Olena. Una, dos preguntas más porque tenemos unos tres minutos para esto. Con más datos siendo generados por IA cada día, ¿crees que la contaminación cruzada es inevitable en el futuro cercano? Sí, así que, y como entiendo esta contaminación cruzada es que tenemos ataques donde en realidad la información engañosa simplemente se repite en diferentes fuentes. Se inyecta como en todo el tablero y luego cuando el modelo va allí, por supuesto, el modelo, esto también es la confianza del modelo, cómo decide qué información usar en la respuesta y qué información es menos confiable. Si es la misma información en diferentes fuentes, la encontraría más confiable. Así que, esa contaminación cruzada se vuelve más y más peligrosa a medida que aumenta el número de ataques. También es este tipo de pendiente de IA, que es como simplemente información duplicada a través de las fuentes aumenta. Así que, sí, veo eso. Increíble, fantástico.

Y luego nuestra última pregunta, ¿son los LLMs la mejor herramienta para analizar flujos? Antes de los LLMs, teníamos todos esos algoritmos difusos para encontrar eventos sospechosos como el clasificador bayesiano, usando filtros de spam. ¿Son los LLMs mejores o solo están de moda? Yo diría que los LLMs no son mejores. Así que, los LLMs tienen su papel y en ciertas situaciones los LLMs son perfectos. Pero en muchas situaciones, en realidad, si tienes un modelo de aprendizaje automático, que está diseñado para enfocarse en un problema particular, será más rápido. Si tomas un modelo estadístico matemático, podría ser incluso más rápido y más barato de ejecutar. Así que, diría que necesitamos usar herramientas que sean buenas para diferentes, como tenemos diferentes desafíos que resolver. Así que, pero no deberíamos descartar otros modelos porque los LLMs son más caros, tardan más, y a menudo no son mejores resultados. Tampoco son deterministas. Fantástico. Muchas gracias, Alina. Un aplauso para Alina. Gracias.