Cómo la Alfabetización en Privacidad de Datos Está Moldeando la Infraestructura

Hola a todos. Hoy hablaré sobre los límites difusos del diseño de infraestructura y, más específicamente, cómo nuestros usuarios y diseñadores están moldeando nuestra infraestructura. Para aquellos que no me conocen, hola, mi nombre es Megan y soy líder de diseño en Cloudflare. Allí trabajo en nuestra plataforma para desarrolladores y productos de IA, pero en el pasado también he trabajado en clasificación de ML, mapas y computación espacial, AR, VR y tecnologías XR. A partir de algunas de mis experiencias anteriores, puede quedar claro que paso mucho tiempo trabajando en la intersección entre tecnología y diseño. Eso significa que paso bastante tiempo en lugares donde normalmente no se encuentran diseñadores, profundizando en la tecnología, comprendiendo lo que nuestros usuarios necesitan y repensando cómo podemos utilizar la tecnología existente o incluso inventar nueva tecnología para satisfacer mejor a nuestros usuarios. En mi tiempo en este puesto, he aprendido que este enfoque a veces puede parecer bastante radical, especialmente a medida que nos adentramos más en la estructura. Y mi opinión es que los límites entre el diseño de interfaz, el diseño de front-end y el diseño de back-end en realidad no existen. Son creados artificialmente por nosotros, y eso tiene sentido porque así es como construimos nuestros productos en la mayoría de la tecnología. Pero hoy les mostraré que estos límites se están difuminando a través de dos cambios principales que he observado en nuestra industria. El primero es un cambio en nuestros usuarios, y es que se están volviendo cada vez más alfabetizados en tecnología, difuminando las líneas entre el diseño de interfaz y el diseño de infraestructura. El almacenamiento en la nube es un gran ejemplo de esto, donde una solución muy centrada en la infraestructura se ha convertido en un producto para el usuario. Las necesidades de los usuarios están dando forma directamente a cómo diseñamos y construimos nuestra infraestructura hoy en día. Mi segunda observación es que la tecnología que utilizamos para construir nuestra infraestructura también está cambiando, y esto está dando forma a cómo construimos nuestra infraestructura. Se está volviendo cada vez más permutable, difuminando las líneas entre el diseño de front-end y el diseño de back-end. La mayoría de los desarrolladores ahora se consideran de pila completa y necesitan tomar decisiones tanto en el back-end como en el front-end que deben incluir las necesidades de nuestros usuarios. La combinación de estos dos cambios juntos está dando forma no solo a cómo diseñamos nuestra infraestructura, sino también a quiénes deben participar en esas decisiones y quiénes se consideran, especialmente aquellos que están moldeados por las necesidades de nuestros usuarios, y ese papel a menudo lo desempeña el diseño. Ahora, antes de seguir adelante, quiero repasar ambos cambios con un poco más de detalle. El primer cambio es un cambio que hemos visto en nuestros usuarios, específicamente en su alfabetización técnica. Si no estás familiarizado con este término, la alfabetización técnica del usuario se refiere realmente a cuánto comprenden nuestros usuarios la tecnología subyacente que impulsa las aplicaciones que utilizan. Para mostrar este cambio, voy a repasar una línea de tiempo que tiene cuatro hitos importantes. Estos hitos destacan un cambio en la mentalidad de nuestros usuarios sobre cuánto entienden la tecnología que están utilizando, y ha ocurrido durante la última década aproximadamente. Esto se hará a través del prisma de la privacidad, pero no quiero centrarme demasiado en los momentos específicos de privacidad, sino en los cambios en nuestros usuarios. Así que vamos a ello. Todo comenzó hace unas décadas cuando, como resultado de las redes sociales, comenzamos a compartir nuestras identidades reales en línea. Esto, si lo recuerdas en ese momento, llevó a un debate bastante generalizado que condujo al primer cambio en la alfabetización técnica del usuario, la conciencia. Ahora comenzamos a ser más conscientes de la tecnología subyacente que impulsa nuestras aplicaciones. Unos años más tarde y varios incidentes bastante virales después, comenzamos a darnos cuenta del peligro de un mercado de datos no regulado, y eso nos obligó como usuarios a educarnos sobre cómo funcionan los sistemas, lo que llevó al segundo cambio, la educación sobre la tecnología que estamos utilizando. Incluso unos años más tarde y aún más incidentes, la legislación y la cobertura de noticias nos obligaron a profundizar aún más en la comprensión de cómo funciona exactamente esta tecnología, y esto llevó a un tercer cambio. Ya no solo estábamos educados, sino que también nos convertimos en expertos opinantes y matizados sobre la tecnología que estamos

utilizando. Y eso nos lleva a donde estamos hoy, esperado. Ahora se espera de nuestros usuarios que construyamos nuestra privacidad primero en nuestros productos, y ellos tienen expectativas muy claras sobre nosotros como constructores en cuanto a lo que quieren y lo que debería hacer. Ahora, en este punto, es posible que estés pensando, eso está bien y todo. Pero, ¿qué tiene que ver esto con cómo diseñamos nuestra infraestructura? Y si eso es lo que estás pensando, está bien, porque eso no es lo que somos hoy en día. La mayor parte de la conversación se ha centrado principalmente en asegurarnos de no recopilar información de identificación personal, o PII, o datos sensibles, especialmente si no es necesario para nuestra aplicación. Si profundizamos un poco más, a menudo se trata de cómo explicamos estos conceptos bastante complejos a nuestros usuarios en la UI. Y aunque lo que recopilamos y cómo lo explicamos a los usuarios es muy importante, si nos quedamos solo ahí, parece que estamos deteniéndonos antes de terminar nuestro trabajo. Y eso se debe a que realmente no se trata solo de lo que recopilamos. La parte que creo que se habla un poco menos es todas las decisiones que se toman después de decidir qué recopilar. Comienza con cómo se procesa o transforma esa data por nuestra aplicación. Continúa con dónde se almacena esa data y cómo se gestiona, quién tiene acceso a ella. Y se vuelve aún más complejo hoy en día por cómo esa data podría ser utilizada posteriormente para otros casos de uso derivados, como el entrenamiento de modelos de AI. En un mundo de cloud computing, publicidad personalizada y AI, ya no es suficiente hablar solo de qué data recopilamos, sino también de qué hacemos con ella. Ahora, si esto fue un poco conceptual, no te preocupes. De hecho, voy a mostrar un ejemplo real de cómo esto se ha manifestado en nuestra configuración de privacidad, específicamente en iOS en la última década aproximadamente. Si comparas estas dos áreas que ves aquí, notarás una gran diferencia en el matiz, la granularidad, incluso el lenguaje y la complejidad de los controles que ahora ofrecemos a los usuarios. Hace solo unos años, el tipo de lenguaje que usamos en nuestros productos probablemente solo estaría disponible en algún tipo de modo de desarrollo o no se mostraría a nuestros usuarios en absoluto. Pero ahora esto no solo es una expectativa de nuestros usuarios, sino que también es algo sobre lo que tienen opiniones bastante sólidas y matizadas, por eso nuestros controles son tan granulares hoy en día. Y esto no solo está cambiando nuestras interfaces, sino también cómo construimos nuestras aplicaciones. Los desarrolladores de aplicaciones ahora se ven obligados a diseñar sus aplicaciones para adaptarse a estas características de usuario muy populares, cuándo y cómo se recopilan los datos, ya sea de forma continua, en primer plano, en segundo plano, qué tan precisa puede ser esa data, con qué frecuencia se actualiza. Estas son todas cosas que solían ser principalmente decisiones de funcionalidad de ingeniería que ahora tienen muy en cuenta las necesidades y la privacidad de los usuarios. Lo que esto realmente significa en su conjunto es que las necesidades de los usuarios ahora están dando forma a cómo diseñamos nuestra infraestructura. Y eso nos lleva de vuelta a mi punto original, que espero que ahora quede más claro cómo están cambiando los usuarios y que son más técnicamente alfabetizados que nunca. Y este cambio en nuestros usuarios está haciendo que sus necesidades no solo informen, sino que den forma a cómo construimos nuestra infraestructura. Y donde encuentres usuarios, también deberías encontrar diseñadores. Pero no solo los usuarios y el diseño están evolucionando, también hay un gran cambio que viene del lado técnico. Y eso nos lleva a la segunda gran observación que he visto. Ahora, antes de entrar en esta próxima parte, quiero aclarar que de ninguna manera soy una experta en infraestructura. Después de todo, soy diseñadora. Así que me disculpo de antemano si esta no es la parte más técnicamente precisa de mi presentación, pero espero que me des un poco de margen y no te enfoques demasiado en eso.

No me voy a enfocar tanto en eso. En cambio, lo que realmente quiero destacar en esta sección son los cambios en la tecnología que utilizamos para construir nuestra infraestructura y específicamente, los cambios en los principios de cómo abordamos la construcción y cuánto están involucrados los usuarios y los diseñadores en estas decisiones. Y una vez más, voy a recorrer estos cambios a través de una línea de tiempo de la evolución de la infraestructura. No quiero centrarme demasiado en la precisión técnica o cronológica aquí. En cambio, lo que destacaré son los grandes cambios en las prácticas, específicamente, las mejores prácticas de cómo construir infraestructura y qué las motivó. La dirección general que deberías ver es una difuminación entre el límite de la infraestructura de front-end y back-end diseño. Pero lo más importante, quiero destacar que gran parte de este cambio hasta ahora ha sido informado por decisiones de rendimiento de ingeniería y experiencia de desarrollo. Así que empecemos. Al principio, la mayoría de los desarrolladores tenían un control mínimo sobre dónde ejecutaban su aplicación y todos seguían el mismo estándar global general de que las aplicaciones se ejecutaban en un solo servidor. Luego, unas décadas más tarde, decidimos separar los front-ends para que se ejecuten en redes de entrega de contenido. Esto fue el comienzo de la elección en el diseño de la infraestructura, aunque aún era principalmente una conversación de ingeniería. Podías decidir optimizar tu rendimiento o facilitar la escalabilidad moviendo partes de tu infraestructura fuera de los servidores. Luego, unos años más tarde, nos dimos cuenta de que podíamos comenzar a ejecutar cómputo en CDN, lo que llevó al cómputo sin servidor. Esto dio a los desarrolladores aún más flexibilidad para elegir qué partes de su aplicación querían ejecutar en el lado del servidor utilizando frameworks de pila completa como React. Pero una vez más, gran parte de esta discusión y gran parte de este cambio se centró en la experiencia del desarrollador y el rendimiento de ingeniería. Y luego llegamos a donde estamos hoy, o en realidad hace un año y medio aproximadamente. Con el lanzamiento de los componentes del servidor de React y otros servicios similares en el cliente y en el servidor, los desarrolladores ahora tienen más opciones que nunca para construir y decidir dónde construir y ejecutar sus aplicaciones. Ahora, una vez más, es posible que estés pensando, eso está bien y todo, pero ¿qué tiene que ver esto con la forma en que los usuarios dan forma a nuestra infraestructura? Y la verdad es que hasta ahora no lo tiene. No he visto mucha conversación sobre cómo esta tecnología puede ser utilizada para brindar funcionalidad al usuario y ayudar a los usuarios a tener más voz en cómo construimos nuestra infraestructura.

Principalmente creo que se debe a que todavía estamos en los primeros días de comprender cómo se puede utilizar esta tecnología y cómo pensar en ella. Así que estoy aquí para discutir ese cambio con todos ustedes hoy. Ahora, ha habido mucha expectación en torno a los componentes del servidor de React y no soy una experta. Pero con solo un vistazo rápido, he visto que gran parte de esta discusión se ha centrado en dos cosas principales, el rendimiento y la experiencia del desarrollador. El primero se centra realmente en la permeabilidad de los tiempos de carga y la optimización del renderizado para pantallas de brillo como las que ves aquí hoy. El segundo se centra mucho en la simplicidad del código con la recuperación de datos. Y aunque esto es realmente interesante, siento que es solo un primer paso de lo que ahora podemos hacer con esta tecnología. Como no desarrolladora, las oportunidades que esto habilita y que encuentro más interesantes están más relacionadas con la privacidad y la seguridad. Ahora podemos preguntarnos qué código o datos no deberían estar expuestos en el cliente o en el servidor. Y podemos decidir y diseñar una infraestructura permutable en función de la respuesta a esa pregunta. Esto puede empoderar a nuestros usuarios con la confianza de que sus datos sensibles nunca saldrán de su dispositivo. Y de manera similar, puedes mejorar tu propia seguridad para tu infraestructura

al evitar que code o data se expongan al cliente. En otras palabras, ahora tienes total flexibilidad para design tu infraestructura para satisfacer tanto tus necesidades como las de tus usuarios. Pero esta no es una decisión fácil de tomar, y creo que se debe a que es un territorio nuevo y puede ser bastante sutil. Con esta capacidad y responsabilidad, ahora estás definiendo límites entre el servidor y el cliente como nunca antes. Y creo que esto será bastante único para cada aplicación o incluso para cada caso de uso dentro de tu aplicación. Es una elección explícita que debes hacer para definir dónde vive el data, dónde se transforma y cómo se almacena entre el cliente y el servidor. Y no siempre es sencillo. Y ahora tenemos la carga y el privilegio de tomar esa decisión nosotros mismos. Pero si esto parece abrumador, no te preocupes. Ya tenemos algunas bibliotecas iniciales diseñadas para ayudarte a gestionar esto. React ha lanzado algunas API experimentales diseñadas para evitar que los data se expongan al cliente para información muy sensible como secretos u otros data seguros. Pero quiero destacar en este momento, una vez más, que la mayor parte del enfoque ha estado en las herramientas para desarrolladores. Sin embargo, soy optimista de que con la entrada de más diseñadores en esta conversación y la evolución de esta tecnología, comenzaremos a ver API similares para la sensibilidad de los datos de los usuarios, evitando que los datos fluyan del cliente al servidor. Para concluir, la tecnología nos ha dado más control que nunca sobre cómo construimos nuestra infraestructura. Y los límites entre el front-end y el back-end dependen de ti para definirlos. Y no es solo una elección de rendimiento o una elección de experiencia de desarrollo. También debe estar informada por nuestras usuarios y sus necesidades sutiles. Estos dos cambios que se unen, los cambios en nuestros usuarios y los cambios en nuestra tecnología, están dando forma no solo a cómo construimos nuestra infraestructura.

pero a quién consideramos en esas decisiones y quién nos ayuda a tomarlas. Y esto es mucho cambio de una vez. Entonces, es posible que te preguntes, wow, esto está bien y todo, pero ¿cómo puedo incluir esto en mi práctica diaria? Bueno, eso me lleva a la parte final de mi charla. Ahora que tenemos tanto la capacidad como la responsabilidad de diseñar nuestra infraestructura, ¿cómo podemos hacerlo de manera que optimice tanto el rendimiento de ingeniería como la comodidad del usuario? Bueno, mi solución es hacerlo con diseño. A medida que las necesidades del usuario comienzan a influir cada vez más en nuestra infraestructura, también lo hacen los diseñadores y las prácticas que utilizan. ¿Por qué no utilizar algunas de las herramientas de experiencia de usuario muy comunes que usamos hoy en día para tomar decisiones sobre cómo diseñamos nuestras interfaces para asegurarnos de que las necesidades del usuario estén en primer plano y también diseñar nuestra infraestructura? Y así voy a guiarte a través de dos ejercicios rápidos que te recomiendo que comiences a agregar a tu proceso. Estas son actividades de diseño muy comunes que se adaptan para ejercicios que podemos utilizar para diseñar nuestra infraestructura. El primer paso es crear un mapa del recorrido de datos. Si has trabajado con diseñadores antes, esto puede sonar muy similar a un mapa del recorrido del usuario. Esto consiste en mapear todos los componentes de tu infraestructura y el flujo de datos del usuario y de la empresa a través de tus sistemas. Luego, utilizaremos este mapa en el segundo paso para identificar los puntos de preocupación y mitigarlos con un diseño de infraestructura muy intencional. Estos ejercicios son bastante rápidos y se pueden hacer por ti mismo, pero recomiendo hacerlos en equipo multidisciplinario. Puntos extra si incluyes a un diseñador.

Reconozco que simplemente compartir estos pasos puede que no sea muy claro, así que en realidad voy a mostrarte un ejemplo de una consulta de recuperación aumentada o REG para que esto sea un poco más claro. Comenzando con ese primer paso de mapear cómo los datos se mueven a través de nuestro sistema. El objetivo aquí realmente es desglosar mi infraestructura en partes más simples. Para este ejemplo, comienza con el usuario o cliente enviando una consulta a un punto final de la API. En mi caso, porque trabajo en Cloudflare, generalmente es un worker. Esta consulta luego se transforma con un modelo de IA en un vector de incrustación. Luego uso este vector para buscar en un índice de vectores para recuperar los vectores relacionados. Sí, acabo de decir vector muchas veces. Basado en estos resultados de la búsqueda de vectores, el sistema recupera un documento relacionado con la consulta inicial. Y algo que quiero destacar aquí es que para nuestro sistema, este es un documento interno. Así que uso un modelo de IA para resumir ese documento, de modo que no se envíe en bruto al usuario, sino que se genere una respuesta de resumen al usuario basada en su consulta inicial. Algunas notas sobre este diagrama. Lo primero es que puedes notar que resalté qué es front-end y qué es back-end aquí. Y eso es porque realmente quería entender cuándo se transferían datos entre estos dos sistemas. Lo segundo que notarás es que la narración que acabo de dar es mucho más compleja de lo que parece ilustrado en este mapa del recorrido de datos. Y eso se debe a que este nivel de complejidad fue suficiente para que mi equipo entendiera y realizara el segundo paso de este ejercicio, dado que todos estamos muy familiarizados con esta tecnología. Y eso es realmente el secreto para un buen data

mapa de recorrido. Solo necesita ser lo suficientemente claro para pasar al paso dos. Entonces, para el paso dos, utilizamos este mapa para identificar los lugares en la infraestructura donde uno, los usuarios podrían tener preocupaciones, o dos, nosotros como organización podríamos tener vulnerabilidades de seguridad. Esto puede ayudarte a identificar puntos donde necesitas definir de manera más intencional los límites entre el cliente y el servidor no solo basados en el rendimiento, sino también en la privacidad y las necesidades de seguridad. Para mi ejemplo, hay dos situaciones de este tipo. La primera está en la consulta inicial que va del usuario al servidor. Quiero asegurarme de que no haya datos sensibles en esta consulta inicial. Y si los hay, no quiero enviarlos a nuestros servidores y pedir a los usuarios que corrijan la consulta. La segunda se refiere más al aspecto de la seguridad, donde quiero asegurarme de que los datos del documento en bruto con información interna no regresen al cliente. Solo el resumen y que no contenga información interna que no deba ser expuesta. En general, todo esto solo tomó unos minutos en este ejercicio con mi equipo, pero fue extremadamente valioso. Y eso es lo último que realmente quiero resaltar. No inventé nada de esto por mi cuenta, ni el diagrama, ni las preocupaciones. Colaboré con mi equipo de ingeniería, ventas, PM y todos mis socios multifuncionales para llegar a este punto. Y eso realmente nos lleva al último cambio que está ocurriendo. Es que a medida que nuestra tecnología evoluciona, también lo hacen nuestros roles. El límite entre la ingeniería y el diseño está más cerca que nunca. Realmente te animo a que comiences a abrir estas conversaciones a más y más personas, especialmente cuando hablamos de IA. Los ejercicios que compartí hoy son actividades de diseño muy comunes. Y creo que al involucrar a los diseñadores podemos obtener perspectivas muy diversas y realmente hacer que las soluciones que construimos sean más robustas. Después de todo, construimos mejores productos juntos. Así que mi llamado a la acción para todos ustedes es que ahora todos somos responsables de diseñar e ingeniar nuestra infraestructura de manera que nos ayude a construir un mejor producto para nuestros usuarios. Muchas gracias por escuchar. Estoy emocionado de verlos a todos en el resto de la conferencia. Transcrito por https://otter.ai