Seguimos viendo a los datos de producción en entornos de prueba como un área de preocupación. En primer lugar, muchos casos de esto han resultado en un daño considerable, por ejemplo, cuando se ha enviado una alerta incorrecta desde un sistema de prueba a toda una población de clientes. En segundo lugar, el nivel de seguridad, específicamente en torno a la protección de datos privados, tiende a ser menor para los sistemas de prueba. No tiene mucho sentido tener controles elaborados sobre el acceso a los datos de producción si esos datos son copiados a una base de datos de prueba a la que pueden acceder las personas desarrolladoras y QAs. Aunque es posible ofuscar la información, esto tiende a aplicarse sólo a campos específicos, tal como números de tarjetas de crédito. Por último, copiar datos de producción a sistemas de prueba puede infringir las leyes de privacidad, por ejemplo, cuando los sistemas de prueba se alojan o son accedidos desde un país o región diferente. Este último escenario es especialmente problemático con despliegues complejos en la nube. Los datos falsos son un enfoque más seguro, y existen herramientas para ayudar en su creación. Reconocemos que hay razones para copiar elementos específicos de los datos de producción, por ejemplo, en la reproducción de una incidencia o para el entrenamiento de modelos ML específicos. Aquí nuestro consejo es proceder con precaución.
Seguimos percibiendo a la producción de datos en entornos de prueba como un área de preocupación. En primer lugar, muchos ejemplos de esto han resultado en daños a la reputación, por ejemplo, cuando se ha enviado una alerta incorrecta desde un sistema de prueba a toda una población de clientes. En segundo lugar, el nivel de seguridad, específicamente en torno a la protección de datos privados, tiende a ser menor para los sistemas de prueba. No tiene mucho sentido tener controles elaborados sobre el acceso a los datos de producción si esos datos se copian en una base de datos de prueba a la que pueden acceder todos los desarrolladores y QA. Aunque puede ocultar los datos, esto tiende a aplicarse sólo a campos específicos, por ejemplo, números de tarjetas de crédito. Por último, copiar datos de producción en sistemas de prueba puede infringir las leyes de privacidad, por ejemplo, cuando los sistemas de prueba se alojan o se accede a ellos desde un país o región diferente. Este último escenario es especialmente problemático con implementaciones complejas en la nube. Los datos falsos son un enfoque más seguro y existen herramientas para ayudar en su creación. Reconocemos que existen razones para copiar elementos
