What 501 hours at Innodata taught me about automation

I just wrapped 501 hours as a Business Process Automation Intern at Innodata. The headline result was InnoParse - a FastAPI document extraction system using PaddleOCR and local LLMs. The deeper result was a different way of thinking about automation work.

The model is rarely the constraint

Going in, I thought the hard part of building HR document automation would be the AI - prompt design, model selection, RAG patterns, all the things you read about online. The hard part was actually fitting the tool into a workflow people already trusted. Their spreadsheets, their column names, their failure modes. If the automation doesn't match the shape of the existing process, it doesn't matter how good the model is.

CPU-only, no API calls

The brief had real constraints. No GPU. 16GB RAM. No outbound calls to OpenAI or Gemini. Documents had to stay on the office workstation. Those limits felt restrictive for the first week and then became one of the better things about the project. They forced me to pick CPU-friendly tools, write careful chunking logic, and lean on smaller local models. The result is something that runs anywhere they put it, without ongoing API costs, and without sending sensitive HR data to a third party.

What changed in how I write code

After 500 hours of writing code that other people will run on machines I don't see, I take logging much more seriously. Output that's helpful at 3am from someone else's terminal looks different from output that's helpful from yours. I name fields the way the team already names them, even when the engineering instinct says to "fix" it. And I write README sections that assume the reader has never seen the code before, because for a team handoff, they haven't.

The biggest takeaway

Automation work that survives a team handoff is automation work that respects the team's existing process. The technical part is real, but it's not the part that decides whether the tool gets used six months later.