No automatices (ni envuelvas como producto) el trabajo de RRHH que un chat de IA ya termina en un paste. Automatiza el trabajo de piso que sigue quemando tiempo después del borrador: archivos, lotes, formatos exactos, hojas en el escritorio y cálculos que corres cada semana. Esa es toda la tesis. Los chatbots que redactan políticas o contestan FAQs están bien como chat. Son una razón débil para shippear software, comprar otro asiento de "IA de RRHH" o decir que la semana ya quedó automatizada. El filtro que uso en tools.danieldiaz.dev, y cuando juzgo ideas de producto para equipos de talento, es directo: si un chat ya lo resuelve, no lo construyo.

Qué NO automatizar cuando el chat de IA ya existe

Parte de una división simple. Los trabajos de lenguaje van al chat. La fricción de ops que sobrevive a la ventana del chat va a un tool, un script o una superficie real de producto. Los trabajos de lenguaje se ven así: reescribe esta política en un español más claro, arma el correo de onboarding, resume las notas de la entrevista, sugiere preguntas para un rol, explícale a un nuevo ingreso qué es una caja. Un modelo es bueno en esa clase de trabajo. No necesitas login, sidebar y un badge de "IA de RRHH" para sacar valor. Necesitas un paste y alguien que lea con criterio. La fricción de ops se ve distinto. El paquete del candidato es un zip de escaneos. El portal quiere una plantilla con una forma de fecha y un delimitador. La nómina y las listas de IDs viven en una máquina en la que el equipo ya confía. Esperan cincuenta afiliaciones, no la fila del demo. El chat puede hablar de esos trabajos. Rara vez los termina como el martes los necesita terminados. Si te saltas esa división, automatizas la capa equivocada. Quedas con texto confiado y la misma cacería debajo. Por eso sigo mandando gente al checklist antes de armar el bot: nombra el trabajo, escribe la condición de apagado y pregunta si lo caro alguna vez fue un problema de tool.

Trabajo de lenguaje que el chat ya cierra bien

Esto es lo que trato como "ya resuelto" para juicio de producto, salvo que el equipo tenga una restricción especial que yo pueda ver y medir:

• Redactar correos, ofertas y notas de onboarding
• Resumir reuniones y paneles de entrevista
• Sugerir preguntas de entrevista o descripciones de rol
• Reescribir políticas internas en un español más amable
• Explicar vocabulario de beneficios (EPS, ARL, AFP, caja) en lenguaje claro

Esos outputs siguen necesitando un humano que conozca labor colombiana y la política de la empresa. El punto es más angosto: producir el borrador ahora es barato. Envolver borradores baratos en un producto no crea leverage. Crea otra pestaña que la gente abre una vez, celebra en un hilo de Slack y abandona cuando aparece la cola de verdad. Una prueba útil: después de que existe el borrador del chat, ¿qué trabajo queda? Si lo que queda es "enviarlo" o "ajustar el tono," no necesitabas un tool. Si lo que queda es renombrar cincuenta archivos, llenar una plantilla de portal o cruzar una hoja contra certificados, el chat solo hizo la parte fácil.

Trabajo de piso que todavía quema horas en RRHH en Colombia

En RRHH y ops de talento en Colombia, las horas que todavía veo desaparecer se ven así. Archivos. Llegan PDFs, escaneos, certificados y zips antes de que alguien pueda decidir. Alguien tiene que renombrar, partir, convertir o empaquetar para que el siguiente paso (revisión, carga al portal o archivo) pase sin una cacería dentro de la carpeta. Lotes. Una cédula limpia en el demo no es el trabajo. Cincuenta cédulas sí lo son. Cincuenta afiliaciones sí lo son. Cualquier cosa que solo funcione en la fila feliz del demo te va a mentir sobre el cycle time. Formatos exactos. Portales y entidades son quisquillosos. Quieren esta plantilla, este delimitador, esta forma de fecha, este orden de campos. Casi bien falla. Un chat que "casi" calza la plantilla igual deja al operador arreglando a mano las últimas cinco columnas. Hojas en el escritorio. Extractos de nómina y listas de IDs suelen vivir en una máquina en la que el equipo ya confía. Un helper útil transforma lo que tienes delante. No te pide subir toda la semana solo para probar una feature. Prefiere helpers que dejen las hojas sensibles donde ya están y te entreguen el export que necesitas. UI y cálculos repetibles. Días hábiles hasta una fecha de ingreso. Contadores. Checklists. Short links para campañas. Los mismos inputs cada lunes. La misma salida correcta. Sin ensayo de por medio. Son aburridos a propósito. Aburrido y correcto le gana a ingenioso y olvidado. Esa es la clase de fricción para la que sirve tools: superficies chicas que quitan un salto. No otro lugar para chatear sobre el salto.

Cómo se ve el filtro en tools.danieldiaz.dev

Mantengo un taller personal aparte del producto de empresa a propósito. Tools es donde shippeo utilidades del día a día cuando el dolor es real y el blast radius casi siempre soy yo. Ahí el filtro se queda estricto porque es fácil engañarte con una UI linda. Antes de sumar algo, pregunto:

1. ¿Puede un chat terminar esto con un paste y una lectura cuidadosa?
2. ¿Lo duro involucra archivos, lotes, formatos exactos, datos en el escritorio o un cálculo que repito?
3. ¿El fallo será ruidoso, o se va a ver como éxito hasta que otro lo note?
4. ¿Apagaría esto si el martes no se acorta?

Si (1) es sí y (2) es no, abro el chat y guardo la ingeniería. Si (2) es sí, considero un tool chico. Si el blast radius es el timeline de contratación de otra persona, eso es otro contrato. Esa separación es por qué tools vive aparte de ECORPA.

Lente de founder: portales y criterio, no resúmenes

Armé ECORPA porque afiliar y verificar en Colombia no es un problema de resumir texto. Son portales, documentos, devoluciones y criterio con datos incompletos. El producto comercial posee esa clase de trabajo. Puedes leer la lección de producto en el caso ECORPA. Este blog no es un pitch deck. El puente suave importa para la pregunta de automatización. Cuando un equipo de talento pregunta qué automatizar primero, los aparto de "IA que responde preguntas de RRHH" y los llevo a la cola que todavía necesita archivos exactos, formatos exactos y un humano que vea la evidencia. Eso es el human-in-the-loop como producto, aplicado antes de comprar otra suscripción. Producto de empresa y tools personales comparten la alergia al teatro. No comparten funnel. ECORPA carga obligaciones cuando un camino se rompe. Tools debería quedarse útil y angosto. Mezclarlos se sentiría conveniente. También emborronaría la promesa.

Una lista de rechazos antes de comprar o construir

Me niego a shippear, recomendar o celebrar como "victoria de automatización de RRHH":

1. Un chatbot cuya única métrica de éxito es mensajes enviados.
2. Un flujo que redacta texto pero deja intactos el lote, la plantilla y el portal.
3. Cualquier cosa cuyo fallo se ve como éxito hasta el día de nómina o de afiliación.
4. Un tool que existe porque el demo se veía inteligente, no porque el martes se acortó.
5. Un claim de "configura y olvida" sobre portales y formatos que no controlas.

Usa esa lista también como filtro de comprador. Si un vendor no puede mostrar cómo se acortan archivos, lotes y formatos (no solo cómo se siente el chat), estás comprando lenguaje, no leverage de ops. Un camino de decisión práctico:

• Abre el chat cuando el output es redacción, explicación o un primer borrador que un humano va a editar.
• Shippea o usa un tool chico cuando el mismo archivo, lote, formato, hoja o cálculo vuelve cada semana y el chat no lo termina limpio.
• Exige una superficie real de producto cuando entran portales de terceros, commits irreversibles y timelines de contratación ajenos. Ahí el criterio tiene que seguir visible.

El filtro, en una frase

Shippea para el trabajo que un chat no termina con un paste. Si lo duro son archivos, lotes, formatos, hojas en el escritorio o un cálculo que corres cada lunes, construye. Si lo duro era "encontrar palabras más amables," abre el chat y guarda la ingeniería para algo que todavía duele después del borrador. Los modelos de lenguaje abaraton lo que es barato de redactar. No cambiaron lo que es caro de operar en RRHH en Colombia. El juicio de producto empieza por notar la diferencia, y por negarte a llamar "automatización" a la capa fácil solo porque trae logo.