Cuando una plataforma falla, la primera pregunta suele ser “¿quién tuvo la culpa?”. La pregunta útil es “¿de dónde proviene el error y quién puede corregirlo?”.
No es lo mismo un error del desarrollo propio que un defecto del motor entregado por el proveedor.
Compara tareas y resultados
Ejecuta procesos generales del sistema y registra resultados:
Prueba procesos completos como registrar recepción, consultar saldo, descargar un documento, registrar entrada de almacén, generar validación y completar un trámite. Cada proceso ayuda a ubicar si el fallo ocurre en interfaz, código, base de datos, infraestructura o servicio externo, en lugar de atribuirlo todo a la plataforma.
Conserva registros del mismo período en todos los componentes y cambia una variable a la vez en un ambiente controlado. Una actualización simultánea puede hacer desaparecer el error sin explicar su origen, o introducir otra falla que confunda la evaluación.
En un caso real de desarrollo, los errores que el cliente experimentaba se repetían en el núcleo proporcionado por el proveedor de la plataforma, no en las adaptaciones realizadas por su propio equipo. La comparación de versiones y ambientes permitió separar la capa que fallaba de la interfaz donde el error simplemente se hacía visible. Esa distinción cambió la discusión sobre responsabilidad técnica.
No bastaba observar quién había entregado la pantalla. Había que revisar registros, dependencias, código y condiciones de ejecución. También podían existir causas concurrentes, y reconocerlas era más riguroso que elegir un solo responsable para simplificar el informe.
El cliente debe preservar versiones, requisitos, errores y registros antes de permitir cambios, y las pruebas deben hacerse sin poner en riesgo producción. El abogado relaciona la causa técnica con las obligaciones contractuales; el peritaje delimita qué componente produce el comportamiento. Que el error aparezca en tu aplicación no significa que lo haya creado tu desarrollador, y que provenga de una plataforma no elimina automáticamente toda obligación de integración o soporte.
El cliente necesita preservar versiones y continuidad; el abogado necesita separar causa técnica y responsabilidad contractual. El peritaje debe documentar qué se probó y qué quedó sin resolver, aceptando causas concurrentes cuando existan. No ejecutes cargas en producción para demostrar tu punto ni permitas cambios sin registro mientras analizas.
Si distintos procesos presentan el mismo error o archivos vacíos, puede existir un patrón de plataforma y no un fallo aislado del usuario.
Revisa origen del defecto
Determina si el error está en:
- Código desarrollado por el cliente.
- Plataforma base.
- Configuración.
- Infraestructura.
- Datos.
- Dependencias externas.
- Actualizaciones.
No atribuyas por intuición. La evidencia debe mostrar dónde se origina y qué componente lo produce.
La imposibilidad de reparar también cuenta
Si el cliente no tiene autorización para modificar la plataforma protegida, no puede corregir el núcleo. Esa dependencia afecta responsabilidad y cumplimiento.
Documenta licencias, restricciones y solicitudes al proveedor. No es lo mismo “difícil de reparar” que “técnicamente imposible con los permisos disponibles”.
Contrato y arquitectura
Revisa quién debía entregar cada componente:
- Descripción arquitectónica.
- Plataforma de desarrollo.
- Módulos.
- Integraciones.
- Soporte.
- Correcciones.
- Validaciones.
El contrato debe responder quién responde por errores del motor y quién responde por el desarrollo realizado sobre él.
Pruebas reproducibles
Registra versión, entorno, pasos y resultados. No cambies código para demostrar que puedes arreglarlo antes de preservar la versión fallida.
Una revisión independiente puede distinguir defectos de plataforma, desarrollo y uso, evitando una acusación generalizada.
La causa debe aislarse antes de asignar responsabilidad
Una falla de plataforma, error de desarrollo o incidente de infraestructura puede producir el mismo mensaje visible. Hay que revisar código, servidor, base de datos, red, licencias y servicios externos con registros del mismo momento. El cliente necesita preservar versiones antes de actualizar; el abogado necesita separar causa técnica y obligación de reparación. El peritaje cambia una variable a la vez en ambiente controlado y no ejecuta pruebas destructivas ni acusa por la pantalla donde aparece el error.
Aísla la falla por componentes
Documenta arquitectura, versiones, infraestructura, integraciones y responsables de cada servicio. Un error visible en la aplicación puede originarse en código, base de datos, servidor, red, licencia o API externa. La pantalla donde aparece no identifica automáticamente la causa.
Conserva registros del mismo período en todos los componentes disponibles. Sincroniza zonas horarias y construye la secuencia desde la acción del usuario hasta el error. Si solo tienes una captura, formula hipótesis y evita presentarlas como diagnóstico concluido.
Reproduce el problema en un ambiente controlado con versiones equivalentes. Cambia una variable a la vez y documenta resultados. Si al sustituir una credencial o servicio desaparece la falla, eso aporta evidencia, pero debe relacionarse con el contrato y las obligaciones de operación.
Revisa quién administraba el ambiente y quién tenía capacidad de corregir cada componente. La responsabilidad técnica por causar un error y la obligación contractual por resolverlo pueden no coincidir. El informe debe distinguir esos planos sin invadir la valoración jurídica.
No permitas que las partes actualicen todo durante la prueba sin conservar versiones y registros. Una reparación puede ser necesaria para continuidad, pero debe quedar trazabilidad del antes y después. Reconocer varias causas concurrentes es válido; no todos los incidentes tienen un único culpable. La conclusión debe explicar el peso de la evidencia disponible y las pruebas adicionales que permitirían resolver lo que todavía queda incierto.
