Do not automate (or wrap as a product) the HR work an AI chat already finishes in one paste. Automate the floor work that still burns time after the draft is done: files, batches, exact formats, desk-local sheets, and calculations you run every week. That is the whole thesis. Chatbots that write policies or answer FAQs are fine as chat. They are a weak reason to ship software, buy another "HR AI" seat, or call the week automated. The filter I use on tools.danieldiaz.dev, and when I judge product ideas for talent teams, is blunt: if a chat already solves it, I do not build it.

What not to automate when AI chat already exists

Start with a simple split. Language jobs belong in chat. Ops friction that survives the chat window belongs in a tool, a script, or a real product surface. Language jobs look like this: rewrite this policy in clearer Spanish, draft the onboarding email, summarize the interview notes, suggest questions for a role, explain what a caja is to a new hire. A model is good at that class of work. You do not need a login, a sidebar, and a badge that says "HR AI" to get value from it. You need a paste and a critical reader. Ops friction looks different. The candidate packet is a zip of scans. The portal wants a template with one date shape and one delimiter. Payroll and ID lists sit on a machine you already trust. Fifty afiliaciones wait, not one demo row. Chat can talk about those jobs. Chat rarely finishes them the way Tuesday needs them finished. If you skip that split, you automate the wrong layer. You get confident text and the same scavenger hunt underneath. That is why I keep pointing people to a checklist before you build the bot: name the job, write the kill condition, and ask whether the expensive part was ever a tool problem.

Language work chat already finishes well

Here is what I treat as "already solved" for product judgment, unless your team has a special constraint I can see and measure:

• Drafting emails, offers, and onboarding notes
• Summarizing meetings and interview panels
• Suggesting interview questions or role descriptions
• Rewording internal policies into friendlier Spanish
• Explaining benefits vocabulary (EPS, ARL, AFP, caja) in plain language

Those outputs still need a human who knows Colombian labor and company policy. The point is narrower: the production of the draft is cheap now. Wrapping cheap drafts in a product does not create leverage. It creates another tab people open once, praise in a Slack thread, and abandon when the real queue shows up. A useful test: after the chat draft exists, what work remains? If the remaining work is "send it" or "tweak the tone," you did not need a tool. If the remaining work is rename fifty files, fill a portal template, or reconcile a sheet against certificados, the chat was only the easy part.

Floor work that still burns hours in Colombian RRHH

In RRHH and talent ops in Colombia, the hours I still see disappearing look like this. Files. PDFs, scans, certificados, and zip dumps arrive before anyone can decide. Someone has to rename, split, convert, or package them so the next step (review, portal upload, or archive) can happen without a scavenger hunt inside the folder. Batches. One clean cédula in a demo is not the job. Fifty cédulas is the job. Fifty afiliaciones is the job. Anything that only works on the happy single row will lie to you about cycle time. Exact formats. Portals and entities are picky. They want this template, this delimiter, this date shape, this field order. Close enough fails. A chat that "almost" matches the template still leaves an operator fixing the last five columns by hand. Desk-local sheets. Payroll extracts and ID lists often live on a machine the team already trusts. A useful helper transforms what is in front of you. It does not ask you to upload the whole week just to try a feature. Prefer helpers that leave sensitive sheets where they already are, and give you the export you need. Repeatable UI and calculations. Business days to a start date. Counters. Checklists. Short links for campaigns. Same inputs every Monday. Same correct output. No essay required. These are boring on purpose. Boring and correct beats clever and forgotten. That is the class of friction tools is for: small surfaces that remove a hop. Not another place to chat about the hop.

How the filter shows up on tools.danieldiaz.dev

I keep a personal workshop separate from company product on purpose. Tools is where I ship utilities for the day to day when the pain is real and the blast radius is mostly mine. The filter stays strict there because it is easy to fool yourself with a cute UI. Before I add something, I ask:

1. Can a chat finish this with one paste and a careful read?
2. Does the hard part involve files, batches, exact formats, desk-local data, or a calculation I repeat?
3. Will failure be loud, or will it look like success until someone else notices?
4. Would I turn this off if Tuesday did not get shorter?

If (1) is yes and (2) is no, I open the chat and save the engineering. If (2) is yes, I consider a small tool. If the blast radius is someone else's hiring timeline, that is a different contract. That split is why tools lives apart from ECORPA.

Founder lens: portals and judgment, not summarization

I built ECORPA because affiliation and verification in Colombia are not a summarization problem. They are portals, documents, returns, and judgment under incomplete data. The commercial product owns that class of work. You can read the product lesson in the ECORPA case. This blog is not a pitch deck for it. The soft bridge matters for the automation question. When a talent team asks what to automate first, I push them away from "AI that answers HR questions" and toward the queue that still needs exact files, exact formats, and a human who can see the evidence. That is human-in-the-loop as the product, applied before you buy another subscription. Company product and personal tools share an allergy to theater. They do not share a funnel. ECORPA carries obligations when a path breaks. Tools should stay useful and narrow. Mixing them would feel convenient. It would also blur the promise.

A refusal list before you buy or build

I refuse to ship, recommend, or celebrate as an "HR automation win":

1. A chatbot whose only success metric is messages sent.
2. A flow that drafts text but leaves the batch, the template, and the portal untouched.
3. Anything whose failure looks like success until payroll day or afiliación day.
4. A tool that exists because the demo looked smart, not because Tuesday got shorter.
5. A "set and forget" claim across portals and formats you do not control.

Use that list as a buyer's filter too. If a vendor cannot show how files, batches, and formats get shorter (not only how the chat feels), you are buying language, not ops leverage. A practical decision path:

• Open chat when the output is wording, explanation, or a first draft a human will edit.
• Ship or use a small tool when the same file, batch, format, sheet, or calculation returns every week and chat cannot finish it cleanly.
• Demand a real product surface when third-party portals, irreversible commits, and other people's hiring timelines are in play. Then keep judgment visible.

The one-sentence filter

Ship for the work a chat cannot finish with one paste. If the hard part is files, batches, formats, desk-local sheets, or a calculation you run every Monday, build. If the hard part was "find nicer words," open the chat and save the engineering for something that still hurts after the draft is done. Language models changed what is cheap to draft. They did not change what is expensive to run in Colombian HR ops. Product judgment starts by noticing the difference, and by refusing to call the easy layer "automation" just because it has a logo.