El post que buscas se encuentra eliminado, pero este también te puede interesar

Responsabilidades del proveedor informático

Anuncios

POR MEDIO DE ESTE POST Y OTROS QUE VENDRAN POSTEARE TEMAS REFERIDO A LA INFORMATICA Y SU MARCO LEGAL!

(SE QUE ES LARGO PARA LEER PERO NO ESTA DEMAS HACERNOS UN TIEMPITO Y LEER PARA ENRIQUESER NUESTROS CONOCIMIENTOS EN ESTE SENTIDO)

Una de las frases más célebres del Código Civil argentino reza que las convenciones hechas en los contratos forman para las partes una regla a la cual deben someterse como a la ley misma. No hay ninguna ciencia oculta tras este inveterado principio legal; lo que dice es simple: lo que las partes pacten libremente en un contrato será la ley que regulará el negocio entre ellas. Y, aunque resulte obvio aclararlo, los contratos de software y servicios informáticos no escapan a este principio.

Sin embargo, no es menos cierto que, junto a lo pactado libremente, se levanta todo un edificio de normas legales que enmarcan la voluntad de las partes dentro de ciertos límites y que esas normas legales toman un cariz propio cuando son llevadas a los tribunales e interpretadas y aplicadas por los jueces. Como suele afirmarse, las leyes y los contratos no siempre dicen lo que aparentemente dicen, sino lo que los jueces dicen que dicen. Es conveniente, entonces, conocer los estándares jurisprudenciales que se suelen aplicar a la hora de interpretar los contratos informáticos, en particular en lo que atañe a las responsabilidades que nacen en cabeza del proveedor de software y servicios informáticos.

La provisión de SSI como obligación de resultado
Lo primero a tener en cuenta es que es opinión unánime entre los tribunales nacionales que la prestación de software y servicios informáticos califica dentro de lo que se conoce como “obligaciones de resultado”, con las consecuencias que esto entraña en materia de responsabilidades para el proveedor de estos bienes y servicios.

Así, en un caso reciente se ha señalado que la licencia de uso de software, la compraventa de hardware, el servicio de instalación de una red de datos así como la prestación de servicios de soporte o mantenimiento constituyen típicas obligaciones de resultado para la empresa proveedora. Como puede apreciarse, la enumeración abarca todo el abanico de negocios referidos al sector TI: hardware, software y servicios informáticos. Ahora bien, ¿qué quiere decir esto? Veamos.

Desde el plano legal, las obligaciones de resultado se distinguen de las obligaciones de medios. Así, por ejemplo, si yo le encargo a un carpintero un juego de living para mi casa, el carpintero asume una obligación de resultado, a saber: entregarme el juego de living que le encargué. Lo mismo sucede cuando alguien compra un auto: el vendedor asume la obligación de entregar el auto. Ambas son obligaciones de resultado, porque el deudor sólo cumple su prestación si obtiene el resultado o fin al que se comprometió, independientemente del esfuerzo, trabajo, diligencia, etc., que haya puesto para lograr su obtención.

En cambio, si voy al médico porque me aqueja cierto malestar, el médico asume una obligación de medios, no de resultado. ¿Por qué? Porque su obligación radica en poner toda su diligencia, saber, prudencia y demás virtudes propias de su profesión, a los efectos de darme un tratamiento adecuado, pero no está obligado a curarme efectivamente. Similar situación es la de los abogados cuando son contratados para llevar adelante un juicio, cuya obligación estriba en poner su diligencia, saber, etc., a los efectos de defender adecuadamente los intereses de su cliente, no estando obligados a ganar el pleito.

La diferencia entre ambas categorías de obligaciones impacta en muchos aspectos de la relación comercial entre las empresas proveedoras de soluciones informáticas y sus respectivos clientes, alcanzando, incluso, a las propias cláusulas contractuales que las partes puedan haber acordado libremente.

El criterio de la utilización efectiva de la solución tecnológica
Un primer aspecto que la jurisprudencia local ha derivado del carácter de obligación de resultado que tienen las prestaciones SSI se vincula con la obligación de entrega. ¿A partir de qué momento una empresa proveedora de soluciones informáticas cumple con su obligación de entrega del producto o prestación del servicio?

En un caso llevado a los tribunales, los jueces resolvieron que la sola carga del programa no basta, siendo necesario que el adquirente pueda utilizarlo efectivamente. Es decir, a la hora de evaluar el cumplimiento de la prestación se aplica el criterio de la efectiva utilización por parte del adquirente o usuario.

Como suele decirse, cuando alguien adquiere una computadora pretende que funcione. Nadie adquiere una computadora o sistema informático que no funcione, que, por ejemplo, muestre siempre la pantalla en negro o que reste cifras cuando el usuario quiera sumarlas.

En esta línea de razonamiento, se ha resuelto también que a los efectos de la aceptación del sistema informático adquirido y de la asunción de la obligación de pago por parte del adquirente, es necesaria la operación conforme del conjunto de los elementos componentes del sistema y su utilidad y adecuación a los fines previstos, no bastando la mera entrega física del equipo adquirido ni, tampoco, la instalación y puesta en marcha de los elementos.

Y es por eso que la aptitud del sistema es responsabilidad de la empresa proveedora, quien debe arbitrar los medios necesarios para obtener el resultado, esto es, determinar el hardware, el software y los servicios pertinentes.

Ahora bien, es importante señalar que el criterio de la utilización efectiva como parámetro para calificar la obligación de resultado que asume el proveedor se limita a la provisión de las soluciones contratadas, no extendiéndose a los resultados de su aplicación a la operatoria concreta de la empresa adquirente. En este sentido, si alguien adquiere un software de administración o de contabilidad, la obligación del proveedor es que ese software haga lo que debiera hacer, no que la contabilidad de la empresa adquirente arroje saldo positivo ni tampoco que ésta ahorre tiempo o dinero por la implementación del sistema.

Finalmente, se ha resuelto también que si no se arriba al resultado previsto por inconductas del adquirente, la empresa de software no incumple con su obligación. En otras palabras, puede suceder que el adquirente no esté en condiciones de utilizar efectivamente la solución adquirida, pero si eso acontece por inconductas suyas (falta de colaboración con el proveedor, falta de carga de los datos, falta de actualización del hardware conforme lo asesorado por el prestador, etc.), la empresa proveedora no será responsable y habrá cumplido con su parte.

¿Quién y qué se debe probar?
La categorización de las prestaciones informáticas como obligaciones de resultado, sumado al criterio de la utilización efectiva de la solución por parte del adquirente, impacta fuertemente en un tema de suma relevancia para los supuestos en que se llegue a un juicio por incumplimiento de alguna de las partes: el de la carga de la prueba del incumplimiento.

Supongamos que la empresa proveedora demanda al adquirente el pago del saldo del monto acordado contractualmente y éste contesta que no está obligado a pagar nada porque la solución provista nunca funcionó correctamente. Es más, aprovechando el pleito ya iniciado, el adquirente demanda a su vez que se resuelva el contrato y que la empresa proveedora le devuelva el dinero y le pague los daños y perjuicios derivados de su incumplimiento. ¿Quién debe probar el incumplimiento alegado por el adquirente?

En un famoso fallo de principios de los ’90 se sentó el siguiente criterio:
- Si el incumplimiento es parcial (por ejemplo, el proveedor debía entregar 5 programas y entregó sólo 3) la empresa proveedora debe probar la entrega de los programas, pero el adquirente carga con la prueba de que los programas son inadecuados o funcionan mal y, por ende, no se corresponden con sus necesidades o intereses;
- Si el incumplimiento es total (por ejemplo, el proveedor debía entregar 5 programas y no entregó ninguno) la empresa proveedora debe probar que cumplió, es decir, que entregó los programas y que éstos funcionaban adecuadamente.

Ya en esta década, otro fallo sentó el criterio de que el adquirente debe probar acabadamente la inutilidad o ineficacia del software.

Sin embargo, en un fallo reciente los jueces dijeron que atento que las prestaciones informáticas son obligaciones de resultado, acreditado por parte del adquirente que el sistema provisto no satisfizo su interés final al celebrar el contrato, es decir, acreditado el mero incumplimiento material o estructural de la solución provista (por ejemplo, que presentaba fallos al cargar la información), corresponde al proveedor probar acabadamente que esa falta de satisfacción del interés del adquirente se produjo por una causa ajena (por ejemplo, que el software no funcionó por falta de capacidad de procesamiento de las computadoras del adquirente).

Técnicamente esto significa que la responsabilidad del proveedor informático es objetiva. Traducido, el fallo comentado disminuye la carga de la prueba que pesa sobre el adquirente (sólo debe probar el incumplimiento material o estructural) y aumenta la que pesa sobre el proveedor (deberá probar que el mal funcionamiento responde a una causa ajena a su voluntad).

El fallo agrega un comentario ilustrativo de la visión que tienen los jueces sobre los contratos informáticos. Señala que el criterio mencionado es justo dado que al proveedor informático le resulta mucho más fácil probar cuál es el defecto que provocó la no consecución del resultado esperado, teniendo en cuenta la brecha tecnológica que separa a las partes en este tipo de contrataciones. Si bien el concepto de “brecha tecnológica” amerita algunos comentarios críticos, que no es del caso realizar en esta oportunidad, no queríamos dejar de señalar que está presente en las argumentaciones de los tribunales locales.

Software estandarizado y parametrizado
El último punto que queremos tratar es el de la aplicación del concepto de obligación de resultado al software estandarizado.

Contra lo que pudiera parecer a primera vista, la jurisprudencia nacional es unánime a la hora de considerar que la provisión de software entraña una obligación de resultado, se trate de software a medida o estandarizado. En ambos casos, el proveedor se compromete a satisfacer el interés del adquirente de que el software funcione adecuadamente y satisfaga el fin tenido en mira por él al adquirirlo.

No obstante, en un caso se precisó que en el supuesto de provisión de software estandarizado no se exige que sirva efectivamente a todas y cada una de las especiales circunstancias del adquirente, razón por la cual en otro fallo se indicó que cuando se contrata un sistema estandarizado, no existe necesidad de especificar requerimientos concretos por parte del usuario.

Esto tiene particular relevancia a la hora de evaluar la responsabilidad del proveedor de software estandarizado en aquéllos casos en que el adquirente hace requerimientos que exceden la parametrización, implicando modificaciones sustanciales que exigen tareas de reprogramación.

Observaciones finales
Si bien el principio de que las convenciones hechas en los contratos forman para las partes una regla a la cual deben someterse como a la ley misma sigue siendo uno de los pilares de la legislación argentina, es importante tener en cuenta la totalidad del marco legal dentro del que se mueven los contratos informáticos y, sobre todo, la interpretación y aplicación que los jueces hacen de ese marco legal.

Ciñéndonos a lo tratado anteriormente, el proveedor de soluciones informáticas debiera estar atento a todo esto a la hora de iniciar las negociaciones con cliente potencial, al momento de redactar las cláusulas del contrato con su cliente y, finalmente, a la hora de ejecutar el contrato conforme lo pactado. Proporcionar adecuada información al cliente, redactar las cláusulas del contrato con precisión y claridad y dejar sentado el cumplimiento de sus obligaciones son algunas de las claves para tener una relación comercial exitosa y evitar largos y costosos conflictos.


FUENTE: http://www.carranzatorres.com.ar/images/pdf/responsabilidades-del-proveedor-informatico.pdf

P_a_S

Anuncios

0 comentarios - Responsabilidades del proveedor informático