Johan Polhem / Applied AI
I take AI out of the pilot and into the P&L.
I have spent fifteen years building businesses that had to pay their way. I grew a production business to more than 80 people across Singapore and Sydney, built and sold an agency, and cofounded a venture firm. At INVNT, I led AI and innovation across Sydney and APAC, taking generative AI and spatial computing into live productions and customer experiences for major enterprise clients. I am presently investing into and building MK8, an applied AI business in Singapore.
AMA
Ask Me Anything.
This chatbot runs on a frontier model given a curated knowledge base of my career, experience and projects, with code checks on every answer.
How I work
I generally don’t sell time. I deliver outcomes. I start with the business problem and how it is solved today. Then I determine what the technology should do and how. Sometimes that means less AI than you expect. Every project is scoped around a measurable outcome. I believe that charging based on how long something takes is counter productive. There is no value in time. If that sounds right, reach out at the bottom of this page.
From weights to the boardroom
Enterprise AI breaks down when technology and business work in isolation. I am fluent in both. These are the rules I build by, and I hold them until the evidence says otherwise.
- Models guess when they don't know. Plan for that.
- Leaderboards mislead. Test models on your own tasks.
- Every answer comes with a cost. Know it before you scale.
- The right data usually beats a bigger model.
- Fine tuning is rarely the first answer.
- Models fail quietly. Build checks in code.
- Automate a messy process and you get a faster mess.
- Decide where the human signs off before you build.
- Let it read widely. Let it write narrowly.
- If you cannot measure it, you cannot defend it.
- Start with the most boring process. It pays first.
- Value hides in friction everyone has learned to live with.
- Measure today before you change anything.
- Never promise a number you cannot measure.
- Data is rarely ready. Budget for that.
- The tool is easy. The people are the project.
- Decide who will run it before you build it.
Articles
Questions
When an agent fails, the cause is almost always one of three things: a vague job, nobody checking its work, or lack of testing before going live.
The agents that work are boring. They do one narrow job. A real person checks the result, and they were tested on real cases before anyone relied on them.
Start here: can you state your agent's job in one sentence, name who checks its work, and show how you tested it?
Usually one of two reasons. The wrong people running the pilot, or it tries to do too much.
A pilot built to look innovative is built to impress, not to run. The people who will use it every day were never part of the design. And when the scope is a whole department, it gets stuck in workshops, reviews and steering groups until budget and patience run out.
Start with one task, run by the people who will use it.
Start here: name who will run it after launch. If you cannot, it is not ready to be a pilot.
Sometimes, yes. A big name reassures a board, and it gives a leader cover if things go wrong. For a substantial change programme across many countries, that weight is real.
But designing the change and doing it are different skills. Large consulting firms are great at defining problems, but not solving them. The build lives in the details: your data, your systems, and the weeks after launch when things break.
Start here: ask who will actually write and run the system, and whether they will still be there after launch.
It depends on whose risk you mean.
For employees: trusting answers nobody checked, and losing the skills that come from doing the routine work yourself.
For a business: confidential data leaking online, systems with more access than they need, and decisions about people that break rules you already have.
For society: the debates that fill the headlines. They matter, but they are not the risks your business will face this year.
Start here: manage the first two. Give your team an approved tool and one rule: never action an answer you have not checked.
It depends. I build systems that connect to any model, and can switch vendor without a rebuild. When a better or cheaper model arrives, you just swap it.
Today, Claude is stronger with code, and OpenAI is better at engagement. Open weight models are preferable when data must stay in house or when volume makes cost critical. What really matters is what sits around the model: the checks on its answers, the data it can access and the rules for what it can and cannot do.
Start here: ask your vendor what it would take to switch models next month.
By building it into the work they already do, and removing alternative options. Most enterprise AI tools are launched without a plan to ensure people keep using it. Usage peaks in week one and quietly fades.
What works: start from one task the team does every week, build the tool around how they actually do it, and stay with them while they use it on real work. Fix what annoys them fast and measure usage.
Start here: decide before launch who will support the tool for the first ninety days, and what KPI you expect at the end of that term.
The biggest risk is not whether a model trains on your data. It is how the system around it is built.
I build every system around four rules.
1. Limit access. The AI only sees the information it needs for each step, and only what the user is allowed to access.
2. Restrict changes. The AI can read broadly but write only where permitted. These limits are enforced in code, not left to instructions.
3. Outside content is information, never instructions. The system can read emails and web pages, but cannot send, change or delete anything at that stage. Hidden instructions cannot always be detected, so the system is designed to ensure they cannot act on anything.
4. Separate risk. The AI never has access to private data, untrusted content and the ability to send information out at the same time.
Start here: ask your vendor which of these their system enforces in code.
Yes, sometimes. But that is rarely the best use case.
Cutting roles is defensive and for a business in decline: same output, fewer people. Using AI to let the same team serve more customers, or divert their time to more profitable tasks is offensive. That is where the growth is.
Carelessly firing staff and expecting AI to completely replace them can be overly optimistic.
Start here: for each team, ask what they would do with ten more hours a week. Start there.
Build compliance into the workflow, not into a policy nobody reads. Most obligations already exist. What changes is how you prove they are met.
Every system I build has four safeguards: human approval where errors are costly or irreversible, a record of every run, testing against agreed standards before each release, and one named person accountable for the system. Systems that make decisions about people, such as hiring or credit, carry stricter obligations. Review those first with your legal adviser.
Start here: if a regulator asked how a decision was made last Tuesday, could you show them?
Start a conversation
A model reads this first and tells you whether it is a fit. It is a small example of the work.