IA en cobranzas: dónde ayuda y dónde conviene no usarla

La pregunta útil sobre inteligencia artificial en cobranzas no es si conviene usarla. Es qué parte del trabajo se le puede dar. Y para eso sirve una distinción simple, que además define quién responde cuando algo sale mal: preparar, proponer y decidir.

Preparar: acá conviene, y mucho

Preparar es todo lo que ordena información sin comprometer a nadie. La salida se puede verificar de un vistazo y el error, si aparece, es visible y barato.

• Clasificar lo que entra. Trescientos mensajes por día se ordenan solos en «consulta de saldo», «promesa de pago», «reclamo», «pedido de baja de contacto». Una persona verifica por muestreo.
• Leer comprobantes. Extraer monto, fecha y referencia de una imagen. La validación contra el sistema es la que decide, no el modelo: si no coincide, va a revisión.
• Resumir el historial. Qué pasó con este caso, en tres líneas, antes de llamar. Le ahorra al gestor los cinco minutos de leer seis meses de conversación.
• Priorizar la cartera. Ordenar por probabilidad de contacto y de respuesta. El orden es una sugerencia, no una instrucción.

En las cuatro, si el modelo se equivoca alguien lo nota rápido y el costo es un minuto de trabajo.

Proponer: conviene con revisión

Proponer es redactar algo que va a salir con el nombre de la empresa. Acá la IA acelera de verdad —un borrador con el historial ya leído se corrige en veinte segundos— pero el borrador no puede salir solo.

Dos razones concretas, ninguna teórica:

• El tono se equivoca en el peor momento. El mismo mensaje que funciona con un atraso de diez días es agresivo con un cliente que ya reclamó dos veces por un error de facturación.
• Se inventan condiciones. Un borrador que ofrece un plan de pago que la empresa no tiene es un compromiso escrito. Que lo haya escrito una máquina no lo vuelve menos exigible.

La forma que funciona: el modelo redacta, el gestor confirma, y queda registrado qué se propuso y quién lo aprobó.

Decidir: acá no

Hay decisiones que no deberían salir de un modelo, por buenas que sean sus respuestas:

• Aceptar o rechazar una quita.
• Enviar un caso a gestión judicial.
• Informar a un buró de crédito.
• Dar por cancelada una deuda.
• Decidir que a alguien se lo puede seguir contactando después de que pidió que no.

No es una cuestión de precisión. Es que son decisiones con consecuencias sobre una persona y tienen que tener un responsable con nombre. «Lo decidió el sistema» no es una respuesta aceptable ante un reclamo, y en cualquier revisión seria tampoco lo es ante un auditor.

La regla práctica: si la respuesta a «¿quién decidió esto?» tiene que ser el nombre de una persona, entonces la decisión no es del modelo.

Las cuatro condiciones mínimas

Independientemente de dónde se use, cualquier implementación debería cumplir cuatro cosas antes de tocar un caso real:

• Falla cerrado. Ante la duda, el caso va a una persona. Un sistema que sigue de largo cuando no está seguro produce errores que aparecen meses después, cuando ya nadie recuerda el contexto.
• Deja rastro. Qué se le pidió, qué contestó, quién lo aprobó y qué salió. Sin registro no se puede mejorar, ni auditar, ni defender.
• Se mide contra lo anterior. Con la misma definición y el mismo período. Si no mejora algo que ya se medía, no se implementa.
• Respeta las reglas de contacto. Horario, frecuencia y baja de contacto aplicados por el sistema, no por el criterio de cada gestión. Una automatización que no frena cuando alguien pidió no ser contactado es peor que no tener automatización.

Lo que hay que tener antes

Una advertencia que ahorra proyectos: casi todos los usos de arriba dependen de que la información esté en condiciones. Un modelo que prioriza una cartera con 40 % de teléfonos inválidos no prioriza: reordena el desorden y lo devuelve con aspecto de recomendación.

El orden razonable es siempre el mismo. Primero los datos, después el registro de la gestión, después la automatización de lo repetitivo, y recién entonces la parte que aprende. Saltearse los tres primeros pasos es la razón más común por la que un piloto de IA queda en piloto.

---

Nota de trabajo · 21 de julio de 2026 · Inteligencia artificial

Los ejemplos numéricos de esta nota son aritmética ilustrativa y no describen ningún trabajo realizado por VASAK.