El correo llegó a Marta a las 18:12, después de que enviara el parte de un accidente doméstico. «Su solicitud no cumple los criterios aplicables», decía. No identificaba los criterios, no adjuntaba el expediente y ofrecía un enlace para consultar preguntas frecuentes. Marta llamó al número de su póliza. La operadora le explicó que la evaluación la hacía una empresa externa y que no podía ver la puntuación ni cambiarla. El proveedor, por su parte, solo atendía a la aseguradora. Entre ambos, una denegación que afectaba a una reparación urgente no tenía persona responsable, explicación legible ni puerta de entrada.
No es una anomalía administrativa. Es el resultado previsible de comprar una herramienta de decisión como si con ella se comprara también la obligación de responder por sus efectos. Una organización puede encargar tecnología, datos, mantenimiento o soporte; no puede encargar a otro su relación con la persona a la que niega una cobertura. La aseguradora decide usar el resultado, define las reglas del contrato y conserva la capacidad de interrumpirlo. Por eso conserva también el deber de explicar, revisar, reparar y, si hace falta, detener el uso.
El contrato distribuye tareas, no desaparece el deber#
Es razonable que una compañía no programe todos sus sistemas. Un proveedor puede tener una especialización útil para detectar incoherencias, ordenar documentación o señalar casos que conviene estudiar con más detalle. La dificultad aparece cuando el contrato usa palabras amplias —«solución de inteligencia», «resultado automatizado», «modelo propietario»— pero no designa quién hará qué cuando la decisión cause un perjuicio concreto.
Es razonable que una compañía no programe todos sus sistemas. Un proveedor puede tener una especialización útil para detectar incoherencias, ordenar documentación o señalar casos que conviene estudiar con más detalle.
Antes de poner una herramienta en producción, la entidad debe poder responder a preguntas muy sencillas. ¿Qué información recibe el proveedor y con qué finalidad? ¿Qué recomendación devuelve? ¿Quién puede aprobar una denegación? ¿Qué documentos, versiones y registros permitirán reconstruir ese momento dentro de seis meses? ¿Quién atiende a Marta en un idioma comprensible? Si esas respuestas solo están repartidas entre anexos técnicos y condiciones de servicio, el sistema ya está mal preparado para una reclamación real.
La división saludable es clara. El proveedor aporta evidencia sobre el funcionamiento de su producto: versión utilizada, campos que intervinieron, límites conocidos, incidencias similares, cambios recientes y método para conservar registros. La aseguradora responde por la decisión comunicada: por qué afecta a esa póliza, qué norma o condición invoca, qué información puede corregir Marta y qué remedio recibe mientras se revisa. Ninguna de las dos capas sustituye a la otra. Una explicación técnica sin decisión reparable es inútil; una carta amable sin evidencia tampoco permite comprobar nada.
Una denegación debe ser una puerta, no un muro#
Un mensaje opaco convierte el primer día de una incidencia en una carrera de obstáculos. Para evitarlo, una denegación necesita incluir al menos cinco piezas visibles: el objeto exacto rechazado, la fecha y el alcance de la decisión, los motivos expresados en lenguaje corriente, las pruebas o datos que la persona puede aportar y un canal con plazo de respuesta. No hace falta revelar código fuente para decir que faltó una factura, que una fecha no coincidía o que el expediente fue tratado como de riesgo alto por una regla determinada. La opacidad no protege necesariamente un secreto comercial; a menudo protege una cadena de trabajo que nadie ha preparado para ser examinada.
El expediente legible es decisivo. Marta debería poder descargar una versión de los documentos que se consideraron, saber qué dato viene de ella, cuál de un tercero y cuál se infirió, y señalar un error sin tener que adivinar el nombre del proveedor. Si la compañía no puede entregar esa ficha porque el sistema externo no guarda la trazabilidad adecuada, no tiene un simple problema de atención al cliente. Tiene una razón para no utilizar esa herramienta en decisiones que restringen derechos o cobertura.
También importa separar la revisión del gesto de pedir paciencia. Un formulario que promete «estudiaremos su caso» no basta. Debe indicar quién leerá la reclamación, qué facultad tiene para cambiar la resolución, cuándo responderá y qué sucede si falta información. En una reparación por filtración de agua, esperar tres semanas puede equivaler a aceptar que el daño se multiplique. El plazo no es una cortesía: forma parte de la calidad de la reparación.
Suspender no es admitir derrota#
Muchas organizaciones solo imaginan dos estados: la herramienta sigue funcionando o se cancela un contrato costoso. Entre ambos existe una medida esencial: la suspensión acotada. Si aparecen señales de que un cambio de versión está rechazando sin explicación suficiente, que un tipo de siniestro acumula correcciones o que el proveedor no puede reconstruir casos concretos, la aseguradora debe poder impedir que el resultado produzca nuevas denegaciones mientras investiga.
Esa facultad ha de estar escrita antes del incidente. El acuerdo debería fijar umbrales verificables: porcentaje de resoluciones revocadas, ausencia de registro, aumentos inusuales por zona o producto, tiempos de respuesta incumplidos y discrepancias detectadas por revisión humana. También debe definir qué ocurre durante la pausa. Los casos nuevos pueden pasar a una cola humana con una instrucción clara: no empeorar la posición de la persona por una duda creada por el sistema. La suspensión protege a quienes aún no han recibido una decisión y ofrece espacio para reparar a quienes ya la recibieron.
No basta con desactivar una pantalla y anunciar una auditoría. Hay que localizar las decisiones afectadas, avisar proactivamente cuando sea posible, reabrir expedientes, acelerar pagos o medidas provisionales y documentar la corrección. Si Marta tuvo que adelantar el dinero de una reparación imprescindible porque una denegación errónea no tenía revisión útil, la reparación no termina al cambiar el estado de su solicitud. Debe considerar los costes causados por la demora y el modo de restituir una posición que nunca debió empeorar.
Probar el acuerdo antes de necesitarlo#
La mejor forma de descubrir una responsabilidad vacía es hacer un simulacro. La compañía puede inventar un caso con un dato erróneo, pedir al proveedor el historial de la decisión y comprobar qué recibe la persona afectada en cada paso. El ejercicio debería incluir a personal de siniestros, atención, cumplimiento y compras. Si nadie sabe quién tiene autoridad para suspender el flujo, si el historial tarda días en llegar o si el lenguaje de la carta solo lo entiende el equipo legal, el problema no se resolverá bajo presión.
Conviene medir algo más que precisión técnica. Una tabla útil compara denegaciones iniciales y revocadas, tiempos de entrega del expediente, días hasta la respuesta humana, costes de reparación por demora y casos en los que se activó una suspensión. Las cifras deben discutirse con ejemplos completos, porque diez revocaciones pueden revelar un mismo fallo de integración, una regla mal traducida o una categoría que no admite circunstancias habituales. El objetivo no es construir una defensa estadística, sino detectar dónde se está trasladando a una persona el coste de una incertidumbre empresarial.
Marta no necesita saber quién escribió cada línea de software para reclamar con dignidad. Necesita que quien le vendió la póliza se haga cargo de una decisión tomada en su nombre. El paso práctico es añadir a cada contrato de algoritmo externo una ficha de responsabilidad operativa: propietario interno de la decisión, pruebas exigibles al proveedor, canal y plazo de respuesta, criterios de suspensión, protocolo de reapertura y forma de compensar daños por error. Cuando esa ficha se puede ensayar con un expediente realista, el contrato deja de ser una coartada y empieza a ser una herramienta de cuidado.
