Las prestaciones laborales en Colombia no son un problema de redacción. Son un cálculo que corres con los mismos campos cada semana: salario, fechas, tipo de contrato y las reglas que convierten esos inputs en prima, cesantías, intereses y vacaciones. Un chat de IA puede explicar el concepto. Ops necesita una calculadora en el escritorio que puedas volver a correr el lunes sin reescribir el prompt. Esa es toda la tesis. Los modelos de lenguaje sirven para vocabulario y primeras explicaciones. Son una superficie débil para el trabajo que sí cierra la semana: los mismos inputs, el mismo output correcto, sin ensayo de por medio.

Qué son las prestaciones como trabajo de piso

En RRHH en Colombia, "prestaciones" es una familia de obligaciones que vive al lado de la nómina, no un tema de blog. Prima de servicios, cesantías, intereses sobre cesantías y vacaciones tienen reglas. El trabajo del operador es más estrecho que el del manual: toma los hechos de este trabajador y este periodo, aplica la regla y deja un número que otra persona pueda auditar. Lo difícil no es nombrar los conceptos. Lo difícil es repetir el cálculo sin que se desvíe. El salario cambia. Las fechas de ingreso importan. Los periodos parciales importan. El auxilio de transporte puede o no entrar a la base. El tipo de contrato cambia el camino. La misma persona que preguntó "qué es la prima" el mes pasado igual tiene que correr bien la fila del martes. Si lo tratas como trabajo de chat, quedan párrafos fluidos y números frágiles. Si lo tratas como trabajo de piso, quieres campos, defaults y un total que se actualiza cuando cambias un input.

Por qué el chat pierde la corrida del lunes

El chat es bueno explicando. Preguntas qué son las cesantías y recibes una respuesta legible. Preguntas cómo se causan las vacaciones y recibes un esquema. Eso ayuda en onboarding y entrenamiento. No cierra el loop de ops. La corrida del lunes tiene otra forma:

1. Los mismos campos de la semana pasada, con uno o dos valores cambiados.
2. Exactitud por encima del estilo. Casi bien falla cuando alguien cruza contra nómina.
3. Auditabilidad. Un colega debería ver qué inputs produjeron qué línea.
4. Velocidad sin re-prompt. No deberías inventar una conversación nueva para cambiar la fecha de fin.

Una ventana de chat pelea con esa forma. Pegas contexto, esperas que el modelo recuerde la regla y lees prosa buscando un número. La semana siguiente empiezas otra vez. El modelo puede inventar un camino confiado cuando el tipo de contrato pedía otra rama. La falla puede verse como éxito hasta que alguien más se da cuenta. Esa es la misma división que uso en qué NO automatizar en RRHH: el trabajo de lenguaje se queda en el chat; los cálculos repetibles con inputs en el escritorio van a un tool.

Los inputs en el escritorio le ganan a los ensayos subidos

Los inputs que importan viven al lado del operador:

• Salario (y si el auxilio de transporte aplica a la base)
• Fechas (ingreso, inicio de periodo, fin de periodo, fecha de liquidación)
• Tipo de contrato (y el camino que sigue de ahí)
• Días trabajados en el periodo que estás estimando

Esos hechos suelen estar en una máquina en la que el equipo ya confía, al lado de extractos de nómina y listas de IDs. Un helper útil toma lo que tienes enfrente y devuelve la estimación. No te pide subir la semana solo para probar una feature, y no convierte el historial salarial en un transcript de chat que preferirías no guardar. "En el escritorio" aquí significa que el flujo se queda corto: abres la superficie, llenas los campos que ya conoces, lees el total y sigues. Prefiere helpers que dejen las hojas sensibles donde ya están. Esa preferencia aparece en tools.danieldiaz.dev por una razón. El blast radius de un número malo, o de pegar filas de nómina en un chat de terceros sin cuidado, no es teórico.

Qué debería hacer una calculadora (y qué debería negarse)

Una calculadora de prestaciones se gana el puesto cuando es aburrida a propósito. Debería:

• Exponer los campos que ops ya usa
• Actualizar prima, cesantías, intereses y vacaciones cuando cambia un input
• Mostrar la base que usó, para que un humano la pueda cuestionar
• Ser honesta sobre ser una estimación para un trabajador dependiente bajo supuestos declarados

Debería negarse a:

• Respuestas de ensayo cuando basta un número
• Claims de "configúralo y olvídate" sobre reglas y edge cases que no has codificado
• Esconder los inputs detrás de un chat que "lo sacó"
• Pretender que la fila del demo es lo mismo que la cola del martes

Si la superficie no puede mostrar qué salario y qué fechas produjeron el total, no está lista para ops. Si necesita un párrafo de salvedades cada vez que cambias un día, sigue siendo una conversación, no una calculadora.

Puente suave: el tool que uso para este trabajo

Mantengo una superficie chica para exactamente este trabajo en tools.danieldiaz.dev/prestaciones: salario y días de entrada, estimaciones de prima, cesantías con intereses y vacaciones de salida. Los números se actualizan cuando ajustas. Sin Excel. Sin hilo de chat. Ese tool vive en el taller personal a propósito. Tools va aparte de ECORPA porque las promesas son distintas. Tools debería quedarse útil y estrecho. El producto de empresa carga obligaciones cuando se rompe un camino en el timeline de contratación de otra persona. El puente es suave a propósito. Si necesitas una estimación rápida con campos en el escritorio, usa la calculadora. Si estás decidiendo qué automatizar después en ops de talento, usa el mismo filtro: shippea para el trabajo que un chat no cierra con un paste. Archivos, lotes, formatos exactos, hojas en el escritorio y cálculos del lunes van a tools. Vocabulario y primeros borradores van al chat.

Lente de founder sin pitch deck

Construí ECORPA porque afiliar y verificar en Colombia es trabajo de portales, documentos, devoluciones y juicio con datos incompletos. Las prestaciones viven en el mismo país y en la misma realidad de ops de talento, pero son otra clase de problema: reglas e inputs, no cacerías entre entidades. Desde un asiento de founder en ops de talento en Colombia, el juicio de producto es el mismo en ambos. No envuelvas explicación como automatización. No confundas una respuesta fluida con una fila cerrada. Deja al humano donde la falla sería silenciosa y cara. Eso es el human-in-the-loop como producto, aplicado antes de comprar otro asiento de "IA de RRHH". Este blog no es un pitch de ventas de ECORPA. Es una nota sobre cuándo una calculadora es la interfaz honesta.

Un camino práctico de decisión

Úsalo cuando alguien pregunte si el chat "alcanza" para prestaciones:

• Abre el chat cuando el trabajo es explicar vocabulario, enseñarle a un nuevo ingreso qué es la prima o armar una nota en lenguaje claro que un humano va a editar.
• Usa una calculadora cuando el trabajo es volver a correr salario, fechas y hechos de contrato hacia una estimación que puedas revisar.
• Exige una superficie real de producto cuando entran portales de terceros, commits irreversibles y timelines de otras personas. Ahí mantén el juicio visible.

Una prueba útil después de que existe la respuesta del chat: ¿qué trabajo queda? Si lo que queda es "enviar la explicación", no necesitabas un tool. Si lo que queda es cambiar la fecha de fin, recalcular la base y dejar un total para revisión de nómina, el chat solo fue la parte fácil.

El filtro de una frase

Explica prestaciones en el chat. Córralas en una calculadora. Si lo difícil son inputs en el escritorio y una corrida del lunes, construye o usa una superficie chica con campos. Si lo difícil era "encontrar palabras más claras", abre el chat y guarda la ingeniería para el cálculo que sigue doliendo después de que la explicación ya está lista.