Anyone who has ever built an enterprise AI application knows the feeling: you look at the first promising tests, the team is excited, everything seems to go to plan. But a few sprints in, the project just stalls, and not for technical reasons.

I want to explain why working prototypes fail.

A large part of my job as Head of Corporate AI & Efficiency is using AI to take routine work out of business functions like recruiting, marketing, and business development. We started earlier than the “every company has AI” era and, since then, shipped 15+ tools that work inside our teams.

There’s no shortage of AI guides right now, but few show the hard calls you'll face while shipping your own build. In this story, I will share several projects and the lessons they taught us about change management*.*

When we started building the first AI projects, the process followed a usual enterprise inertia: the team invested heavily at the prototype stage, and only afterward did it become clear whether users needed the functionality at all.

Now the first prototype is made by a business analyst or a product person who has talked to stakeholders and gathered requirements. That same person validates it with stakeholders. We start engineering only then, after the evidence of value.

Call that Lesson 0: AI itself has shortened the validation cycle. And when AI development accelerates, requests multiply as well. Now you have to be especially attentive to which ones go to the scope.

This brings me to the first story, I call it "Chartering a private jet to the office."

Lesson 1: Don't overengineer

Travel reporting agent case

The travel team asked us to cut the manual work from their expense-reporting process. The internal system was overloaded with routine: entering every amount by hand, uploading receipts, writing expense descriptions after each trip. The team wanted a real agentic AI they could chat with.

Our analysis showed that maintaining such an AI agent would cost more than the hours it saved. So we changed tactics.

We built a chatbot in Google Chat: a conversational interface combined with function calling buttons. Under the hood, it's Gemini Flash on Vertex AI doing the receipt parsing and a Python script doing the data sync; the whole thing costs us about $54 a month.

The “ordinary” buttons turned out to be the best part! Tapping the button is faster than typing, and our users loved it. It also eliminated hallucinations entirely. We deliberately cut secondary requests, such as weather forecasts or travel guides, that would inflate the budget.

Takeaways

1. Beyond the hyped AI cases sit other solutions: integrations, automated data movement between systems, or even a process redesign. There's no need to build a massive deep learning model that costs $10,000 a month when a simple script does it for $50.
2. Avoid feature creep and keep the scope lean. The professional move is the 80/20 rule: 80% of the value, at 20% of the cost.

Payback beats complex architecture. In other words, don't rent a private jet to commute to the office.

Lesson 2: Involve users early. Find your allies

CV conversion case

It was probably our very first AI project, and the first collision with job security fears.

There’s a routine stream for technical writers: bringing candidates' CVs into a standardized format. We built a service to automate this, but the tech writers found the early versions fell short of their benchmark and wouldn’t touch it. The tool sat idle.

Later, by accident, we found an ally: the recruiters. Different job, same routine. It sat right at the top of their pile. Unlike the writers, they didn't need a final document, just a quick draft to review. The tool fit. One recruiter told me, “I stopped dreading Mondays with more than 60 CVs in the queue”. That's when we knew it had found its user. They adopted it, regrouped around more complex work, and by our count it saved the team 150 hours a month.

Takeaways

1. A tool is only good or bad for a specific job. The same CV service was useless to the writers and gold to the recruiters. Show your tools to different users. Cast wide for who benefits.
2. Involve people at the brainstorming and concept stages. If architects draw up cool concepts in a vacuum, without real users at the table, they miss some real pain.
3. You won’t replace a human’s judgement with AI. But you can pull people out of routine. That frees them to work as experts rather than operators.

Lesson 3: Let compliance redirect you; it shows a better way

Candidate screening automation case

This is a story about how regulations can spin a technical project 180 degrees. Welcome to the world of the EU AI Act.

The request we got was to speed up candidate screening for recruiters. Before writing any code, we ran the idea past legal. In Europe, AI in HR is a high-risk category. Any system that evaluates candidates, even with human review on top, carries the full weight of the regulation: certification before release, external audits, detailed logs, and continuous monitoring. One screw-up, and the high-risk violations run up to 35 million euros, or 7% of global turnover. The potential savings weren't worth the risk.

Instead of AI evaluating the candidate, we built an assistant for the tech lead. It doesn’t score candidates; it generates quiz questions and structures data for the expert. A human delivers the verdict. This kept us out of the high-risk zone and saved the budget.

The lesson cost us nothing because we asked legal first; here's what we learned:

1. The EU AI Act is our new "passport control." If you work in the European market, this law is a framework.
2. Don't try to break through the compliance wall. Keep AI in the role of an analyst or a mirror; humans make decisions. The fastest path is often the one that routes around the regulatory traps.
3. Run a legal audit of the architecture at the start, it's far cheaper than redrawing the architecture later..

One more legal note here: the candidate has to know when AI processes their data, and you are obliged to explain it to them in plain language.

Lesson 4: Three pillars of AI-readiness

"Data first, AI second." There is a dangerous myth that GenAI is smart and will sort itself out. Well, it won’t.

In software, the code is king. You can build a whole user interface on dummy data. But in AI, data is king. The entire project lives or dies on the quality of that data before you write a single line of code for a model. Brilliant code can't fix a bad dataset.

Secondly, infrastructure shock is real. Your tech stack may simply not be ready for the load, or for the specifics of running an LLM. Check it before launch, not after the first crash.

And of course, people. Back in 1963, Donald Schön wrote about the role of “champions” in helping radical new inventions survive inside organizations. His conclusion still holds: to survive corporate resistance, a new idea has to find its "champions," a person or a group that will advocate for it and push it forward.

The best foundation for AI is built simultaneously in architecture, data, and people’s trust. That's how you get from a demo to a tool used by thousands.

Thank you for reading. More lessons and ideas coming soon in Part 2.