¿Qué es la ley relacionada con los conflictos y problemas en la etapa de operación del sistema?

Es bien sabido que en los proyectos de desarrollo de sistemas de TI, pueden surgir diversos conflictos y problemas. Sin embargo, no es cierto que todo esté resuelto una vez que se completa con éxito todo el proceso de desarrollo. Los sistemas de TI utilizados en las empresas, por su naturaleza, suelen manejar grandes cantidades de información confidencial y personal, y pueden surgir diversos problemas incluso en la etapa de operación. Por lo tanto, es importante utilizar el conocimiento legal para considerar y prevenir medidas contra tales situaciones incluso en la etapa de operación.

Cómo cambia la teoría legal en torno a los sistemas en desarrollo y operación

El problema legal típico relacionado con los sistemas de TI utilizados en las empresas es, sin duda, el problema de “incendio” del proyecto en la etapa de “desarrollo”. Los proyectos de desarrollo de sistemas suelen ser grandes empresas que requieren una gran cantidad de personal, dinero y tiempo, y normalmente avanzan con el riesgo de varios conflictos y problemas, grandes o pequeños.

https://monolith.law/corporate/collapse-of-the-system-development-project[ja]

En el artículo anterior, se organizan los tipos de conflictos que suelen ocurrir en una serie de proyectos de desarrollo de sistemas, de acuerdo con el marco legal. Además, lo que caracteriza los problemas legales relacionados con los sistemas de TI es la “obligación de gestión de proyectos” que se supone que el vendedor, un experto en desarrollo de sistemas, debe asumir de manera integral.

https://monolith.law/corporate/project-management-duties[ja]

Por supuesto, después de “desarrollar” un sistema de TI, se pasa a la fase de “operación”. La operación en un sistema de TI, en pocas palabras, se refiere a utilizar y operar el sistema desarrollado para llevar a cabo el trabajo real. A menudo se necesita el conocimiento de un técnico de TI para utilizar el sistema de TI, ya que a menudo es necesario conocer bien sus especificaciones. El hecho de que se requiera conocimiento técnico tanto en el desarrollo como en la operación de los sistemas de TI significa que la distinción entre los dos puede volverse ambigua en la práctica. Un ejemplo que ilustra esto de manera concisa es la existencia de la “obligación de soporte”.

https://monolith.law/corporate/support-obligations-of-vendors-after-system-development[ja]

En el artículo anterior, se presenta un caso judicial que reconoce la “obligación de soporte” como una obligación para proporcionar apoyo para la operación e implementación después del desarrollo, distinguiéndola de la “obligación de gestión de proyectos” que el vendedor asume durante el proyecto de desarrollo del sistema. En otras palabras, también puede haber casos en los que las obligaciones legales del vendedor que acepta el trabajo de desarrollo se determinen teniendo en cuenta las circunstancias de la fase de operación posterior. Además, cuando el desarrollo de un nuevo sistema avanza simultáneamente con la eliminación del sistema antiguo, puede haber problemas como la “migración de datos” del sistema antiguo. En tales casos, la operación del sistema antiguo y el desarrollo del nuevo sistema están estrechamente relacionados.

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

¿Cómo debemos organizar los problemas legales relacionados con la operación de los sistemas?

Como hemos visto, la práctica relacionada con los sistemas de TI está estrechamente vinculada entre “desarrollo” y “operación”. Sin embargo, en la fase de operación, dado que el proyecto de desarrollo ha finalizado, también es necesario considerar los problemas de “obligación de gestión de proyectos” de manera independiente. Para discutir de manera unificada los problemas legales de “desarrollo” y “operación”, es necesario organizarlos en un marco de alto nivel de abstracción, ligeramente más orientado hacia la ley que hacia la práctica. Un ejemplo de esto es la organización desde el punto de vista de la “responsabilidad” legal relacionada con los sistemas de TI, que se explica en el siguiente artículo.

https://monolith.law/corporate/responsibility-system-development[ja]

En el artículo anterior, se explica sobre la responsabilidad por incumplimiento de obligaciones civiles, responsabilidad por defectos de garantía, responsabilidad por actos ilícitos, etc., teniendo en cuenta el contexto de los sistemas de TI. Sin embargo, los casos en los que la responsabilidad por defectos de garantía se convierte en un problema en la operación no son tan comunes, excepto en casos en los que se descubren defectos después de la aceptación. Por lo tanto, primero deberíamos organizar teniendo en cuenta las dos responsabilidades por incumplimiento de obligaciones basadas en el contenido del contrato y la responsabilidad por actos ilícitos que no presuponen una relación contractual.

Primero, consideremos si hay una violación de las obligaciones por parte del proveedor

Si es una responsabilidad por incumplimiento de obligaciones, se discute si hay una violación de las obligaciones contractuales, y si es una responsabilidad por actos ilícitos, se discute si hay una “infracción de los derechos de terceros”. En el caso de la responsabilidad por incumplimiento de obligaciones, los elementos descritos en el Acuerdo de Nivel de Servicio (SLA) se convierten en un problema. Además, tanto la responsabilidad por incumplimiento de obligaciones como la responsabilidad por actos ilícitos requieren intención o negligencia, así que debemos tenerlo en cuenta.

Luego, verifiquemos la situación de los daños en el lado del usuario

La obligación de indemnización se aplica a los hechos de daño que han ocurrido en el lado del usuario. Por lo tanto, ya sea en caso de incumplimiento de obligaciones o actos ilícitos, si no se han producido daños en el lado del usuario, no se incurrirá en la obligación de indemnización.

Además, también debemos considerar la posibilidad de aplicar la compensación por negligencia y las cláusulas de responsabilidad limitada

Además, incluso si el proveedor incurre en una obligación de indemnización, si hay algún tipo de negligencia por parte del usuario, se puede considerar un tratamiento como la compensación por negligencia. Además, si se ha establecido un límite en la cantidad de indemnización en el contrato firmado previamente, la cantidad de indemnización puede cambiar debido a ello. Por ejemplo, en el modelo de contrato llamado contrato modelo del Ministerio de Economía, Comercio e Industria, se establece la siguiente disposición sobre la responsabilidad limitada (la parte subrayada es una adición del autor).

(Indemnización por daños)
Artículo 53 Ambas partes pueden reclamar indemnización por daños a la otra parte si sufren daños debido a una causa atribuible a la otra parte en relación con el cumplimiento de este contrato y el contrato individual. Sin embargo, esta reclamación no puede hacerse después de que hayan transcurrido ○ meses desde la fecha de finalización de la aceptación del producto estipulado en el contrato individual que es la causa de la reclamación de indemnización por daños o la fecha de confirmación de finalización del trabajo.

2. El monto total acumulado de la indemnización por daños del párrafo anterior, independientemente de si es por incumplimiento de obligaciones, responsabilidad legal por defectos de garantía, enriquecimiento injusto, actos ilícitos u otra causa de reclamación, se limitará al monto de ○○○ estipulado en el contrato individual que causó la causa de responsabilidad.

3. El párrafo anterior no se aplicará en caso de que se base en la intención o negligencia grave del obligado a indemnizar.

Ejemplos comunes de problemas y disputas que surgen en la operación de sistemas

En la práctica, los ejemplos representativos de problemas y disputas que se pueden esperar en la operación de sistemas incluyen los siguientes:

Accidentes como la pérdida de datos debido a errores del operador

El trabajo relacionado con la operación de sistemas a menudo implica el manejo de secretos comerciales importantes e información personal, y los accidentes pueden ocurrir debido a la negligencia. Un ejemplo de esto es la “pérdida de datos”. Este tema se explica en detalle en el siguiente artículo.

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

Es importante tomar precauciones, como hacer copias de seguridad de los datos, para prevenir accidentes como la pérdida de datos. Si se descuida esta medida, puede ser extremadamente difícil responsabilizar al proveedor que se encargaba de la operación. Por lo tanto, es necesario tener cuidado.

Ataques de seguridad, incluyendo virus

Además, en el caso de sistemas de TI como sitios de comercio electrónico que son utilizados en gran cantidad por un número indeterminado de personas en la web, puede haber grandes incidentes o accidentes debido a ataques de seguridad, incluyendo virus. La detección de estos ataques de seguridad y la implementación de medidas contra ellos también pueden ser parte de las operaciones.

Bugs y fallas que se revelan después de la aceptación

Además, pueden surgir nuevos bugs y fallas después de la aceptación. No siempre es posible considerar exhaustivamente todas las posibilidades de bugs y fallas en el proceso de prueba previo, por lo que pueden surgir después. En estos casos, dado que la entrega ya se ha completado, se considera que el cumplimiento de la obligación en sí mismo se ha completado, y normalmente se exime de la responsabilidad por incumplimiento de la obligación. Sin embargo, en algunos casos, se puede admitir una reclamación de indemnización por daños y perjuicios basada en la responsabilidad por defectos. Este tema se explica en detalle en el siguiente artículo.

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

Resumen

En la etapa de “operación” del sistema, existen numerosos problemas y conflictos que difieren en naturaleza de los proyectos de desarrollo. Sin embargo, al basarse en teorías legales como la responsabilidad por incumplimiento de obligaciones, la responsabilidad por actos ilícitos y la responsabilidad por garantía de defectos, es posible organizar un campo unificado sin ser atrapado por estas diferencias.