Problemas legales asociados con la base de datos del sistema de TI

Al abordar los problemas legales relacionados con los sistemas de TI, se requiere un conocimiento sistemático de la ley, pero al mismo tiempo, es importante entender los componentes de un sistema de TI. En este artículo, organizaremos cómo se compone un sistema de TI, cómo sus componentes interactúan entre sí para funcionar, y explicaremos los problemas legales que están particularmente relacionados con las bases de datos, que son difíciles de ver desde el punto de vista del usuario.

Los sistemas IT se componen de “pantalla” y “lógica”

¿Qué es la “pantalla” en un sistema IT?

Cuando intentamos entender la estructura de un sistema IT, lo más visible es la apariencia de la pantalla. De hecho, en el proceso de desarrollo de sistemas convencionales, después de la “definición de requisitos”, donde se identifican las funciones, normalmente se realiza el “diseño de pantalla” y la organización de la “transición de pantalla”. Esta apariencia en pantalla es un área que naturalmente llama la atención de los usuarios que encargan el desarrollo del sistema, y también es un área donde la comunicación entre el usuario y el proveedor es más probable que sea activa. En el siguiente artículo, explicamos la “obligación de cooperación” que el usuario debe al proveedor para lograr el proyecto en todo el proceso de desarrollo del sistema.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

En este artículo, explicamos principalmente la necesidad de colaborar con el proveedor en fases como el diseño básico (es decir, la pantalla) como parte de la obligación de cooperación que el usuario tiene en el desarrollo del sistema.

La “pantalla” en un sistema IT se describe normalmente siguiendo las reglas de lenguajes de computadora como HTML y CSS. Cuando hablamos de la “pantalla” de un sistema IT, se utilizan varios términos como “front-end”, “UI (Interfaz de Usuario)”, etc., pero el principal punto de discusión es la “facilidad de uso” y la “visibilidad” desde la perspectiva del usuario.

¿Qué es la “lógica” en un sistema IT?

Por supuesto, si un sistema IT se basa en la “pantalla”, entonces es simplemente una “pantalla” que no tiene ningún “movimiento” o “cambio”. Incluso si la recepción de entradas del usuario y la visualización de salidas se realizan en la “pantalla”, hay un “proceso de cálculo” en el proceso.

Estos componentes, que no son visibles para el usuario y que podríamos llamar “la parte trasera del sistema”, realizan cálculos y controles complejos. Los procesos de búsqueda de datos desde la pantalla, reescritura de datos, adición y eliminación, solo son posibles gracias a la existencia de una base de datos construida previamente. Los diversos procesos en la información de la base de datos se realizan normalmente en un lenguaje de computadora llamado SQL.

El hecho de crear un camino desde el botón instalado en la pantalla hasta la ejecución de la sentencia SQL necesaria, es lo que completa la imagen general de un sistema con movimiento y cambio.

Por cierto, las historias relacionadas con la construcción de varias lógicas que no se ven desde la “pantalla” a veces se llaman “back-end”.

El riesgo de discutir sobre sistemas solo desde la perspectiva de la “apariencia” de la pantalla

La explicación hasta ahora sienta las bases de la estructura de los sistemas IT (asumiendo que funcionan en la web). Comprender estos temas tiene un gran significado en términos de discusiones legales, prevención de conflictos en proyectos y gestión de crisis. Concretamente, se puede considerar que pueden surgir malentendidos en la comunicación entre los usuarios que solo se preocupan por la “apariencia” en la pantalla y los proveedores que manejan muchas tareas importantes en el lado “lógico” que no se ve.

El riesgo de que los usuarios y los proveedores tengan puntos de interés completamente diferentes

Por ejemplo, los usuarios que hablan de sistemas IT centrados en la “pantalla” tienden a ser indiferentes a la complejidad de su estructura interna. Por eso, a menudo no comprenden cuánto puede afectar un “pequeño añadido de funcionalidad” o un “pequeño cambio de especificaciones”, que parece insignificante en la superficie. Por ejemplo, el siguiente artículo explica los problemas legales que suelen surgir al desmantelar los sistemas existentes en un proyecto de desarrollo de un nuevo sistema.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Aquí se explica que a menudo surgen problemas al migrar datos al nuevo sistema cuando se desmantela el antiguo sistema. En otras palabras, la complejidad de los mecanismos internos de cálculo y control, que son inimaginables desde la superficie, puede ser una fuente inesperada de problemas para los usuarios. Además, si no se comprende “cómo se siente el proveedor que crea el sistema”, también puede surgir una situación en la que los cambios posteriores se produzcan poco a poco.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

En casos en los que se ordena un cambio de especificaciones o una adición de funcionalidad después del hecho, la posibilidad de un aumento posterior de la remuneración puede convertirse en un problema serio.

https://monolith.law/corporate/increase-of-estimate[ja]

El riesgo de que los usuarios sean indiferentes a la “lógica” detrás de las cosas

Además, las partes que no pueden ser observadas por los usuarios pueden convertirse en grandes incidentes cuando se descubre un problema. Aquí hay un ejemplo de esto.

Riesgo de problemas en términos de mantenimiento y seguridad

Esto incluye situaciones en las que no se pueden implementar funciones adicionales, o el sistema se vuelve cada vez más lento a medida que se usa hasta que deja de funcionar.

Además, hay un método de ataque de seguridad llamado “inyección SQL” que aprovecha las deficiencias en el código implementado en el lado de la pantalla para extraer información personal y confidencial que no debería ser mostrada en la pantalla. El siguiente artículo trata en detalle un caso que se convirtió en un conflicto serio a raíz de esto.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

El tema principal de este artículo son los riesgos asociados con el uso de frameworks y bibliotecas, pero el caso judicial presentado es uno en el que se realizó un ataque a una vulnerabilidad utilizando la inyección SQL.

Riesgo de que la gobernanza no se extienda al trabajo del operador

El hecho de que los usuarios de los sistemas IT sean indiferentes a la “lógica” detrás de las cosas está relacionado con el problema de que la gobernanza puede ser difícil de aplicar al trabajo del operador del sistema. El siguiente artículo explica la importancia del trabajo con bases de datos en el tema de “pérdida de datos debido a la negligencia del operador”.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Riesgo de que la lógica esté equivocada, incluso si parece funcionar correctamente en la superficie

El hecho de que la discusión del sistema no se limite a la “pantalla” significa que incluso un sistema que parece funcionar correctamente en la superficie puede tener una “lógica” errónea. Esto puede revelarse inesperadamente en tareas irregulares como “una vez cada seis meses” o “una vez al año”, incluso si no se hace evidente en las tareas básicas diarias.

En tales casos, se convierte en un problema de responsabilidad por defectos en términos legales (no incumplimiento de la obligación) en relación con un sistema que ha sido entregado una vez y luego se descubre que tiene defectos.

https://monolith.law/corporate/defect-warranty-liability[ja]

Como medida de respuesta en caso de que se descubra un defecto después de la aceptación, el siguiente artículo explica el proceso en detalle.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Resumen

Entendimiento sistemático de desarrollo de sistemas y asuntos legales

En los problemas legales relacionados con el desarrollo de sistemas, es importante entender qué componente del sistema IT es el origen del problema, incluso antes de identificar los puntos de discusión legales. Ya sea un problema legal o un problema con el sistema IT, en los conflictos que surgen en los proyectos de desarrollo de sistemas, se considera especialmente importante no perder de vista la imagen completa y esforzarse en la colaboración entre diferentes industrias.