Tamara Polajnar
Two decades building AI for language, from Cambridge research to shipped products. I still write the code.
About Me
I have been building AI for language for over twenty years. My single greatest work pleasure is solving problems with code and building effective solutions from nothing. I have a proven, successful career in academia, with a PhD in computer science from Glasgow (NLP and machine learning), MSc in Informatics from Edinburgh, tand five years working at the University of Cambridge Computer Laboratory as a postdoctoral researcher in the Natural Language and Information Processing Group. I remain a Visiting Researcher at Cambridge. On the industry side, I was a Chief Science Officer at SenseStreet, where I built models, planned and oversaw data engineering and orchestrated the building of much of the company’s product. I recruited to and managed the development team, and led the science elements of the seed funding round. Today, I run my own AI company and I am the lead developer on its platform, which two UK police forces are currently piloting. On the industry side, I was a Chief Science Officer at SenseStreet, where I built models, planned and oversaw data engineering and orchestrated the building of much of the company’s product. I recruited to and managed the development team, and led the science elements of the seed funding round. Today, I run my own AI company and I am the lead developer on its platform, which two UK police forces are currently piloting. So my background covers research, shipping products, hiring teams, raising money, and I am still actively designing applications and writing code. As an entrepreneur I know how hard it can be to find the right people to help solve the difficult problems or provide key, incisive advice. I’ve experienced the confusion of choice, when the next step isn’t obvious. I bring these experiences to conversation with founders and small teams to help them work through the real decisions: what to build and how to structure your product; which model to choose, what your data will genuinely support, and how you will know whether it is working. I ground conversations in reality and provide balanced, evidence-based advice. My favourite conversations are the ones where someone arrives with a half-formed idea and leaves with clarity about what they can start on Monday.
Specializations
Language technologies (Natural Language Processing, Computational Linguistics, Machine Learning)
My Strengths
Twenty years across natural language processing, information retrieval, retrieval-augmented generation and machine learning, spanning peer-reviewed research and production systems that real people use. I have worked with unstructured text in a variety of domains: biology, chemistry, bond trading, search interfaces for children, fraud, and harm detection for regulated institutions. I can go deep into the technical detail and then explain it in plain language to a board, an investor or a customer, which is a rarer combination than it should be. I have built and managed AI teams, raised money on a technical story, sat on both sides of technical due diligence, and made the hard calls about what not to build. I am direct about what AI cannot do, and I will happily tell you when the answer is a deterministic solution, a trained model, or a prompt.
What You'll Gain
Clarity, and usually a shorter to-do list than the one you arrived with. - A realistic read on whether AI solves your problem, and which part of it - A view on build, buy, partner or wait, with the cost and risk of each - Language you can use with investors and customers without overclaiming - If you are evaluating a vendor: the questions that reveal quickly whether their technology is real - If you are building: an honest assessment of your data, your evaluation approach, and which risks are worth taking seriously
Topics I Cover
AI strategy for founders and small teams: - Product design - Build, buy, or partner decisions - Choosing models and tools, including large language models. - Designing AI features that actually ship. - Getting from prototype to production. - Data readiness: what you have, what you need, and what to do without. - Evaluation: how to tell whether your model is really working. - Natural language processing and text analysis, but also discuss voice, image, video models. - Automating workflows without breaking them. - Rescuing AI projects that have stalled. - Talking to investors about technical products. - Discussion on grants and funding and early startup life.
What to Expect
I like to keep it conversational. If you have something you'd like to send ahead to get more out of the meeting feel free, even if it's not a fully formed idea: a messy question, a deck, a vendor proposal, a product spec, a job description. We spend the first few minutes getting to know each other. It's important to figure out the best way to communicate. We'll then work out what you need, then go wherever is most useful.
Questions & Answers
Usually we can tell within the first twenty minutes. The question is rarely "can AI do this" and almost always "can AI do this reliably enough, on the data you can realistically get, at a cost that still leaves a business". I will take those three apart separately. Sometimes the answer is that a much simpler piece of software solves 80% of it, and I would rather tell you that early than late.
Almost always one of three things: your demo inputs were cleaner than reality, you are measuring the wrong thing, or you have no evaluation set and so you are debugging by vibes. Let's come up with a solution.
We can work through your needs. What is available? Does it work out of the box? Or can it be incorporated into a part-custom solution? What is the long term maintenance like?
Not necessarily, but it changes what you should build. Modern models need far less data than they did five years ago, though you still need enough to know whether the thing works at all. The more useful question is what you could collect in the next three months, and whether your first version can earn its data rather than needing it upfront.
Start with prompting, nearly always. Fine-tuning earns its keep when you need consistent structure, much lower cost at volume, or behaviour you cannot reliably describe in words. Most teams reach for it too early and spend months on something a better prompt and a retrieval step would have handled.
You need a set of examples with known right answers, held back and never used during development. It sounds obvious and almost nobody does it properly. Getting this right is the highest-leverage hour most teams can spend, and it is the thing I most often end up insisting on before anything else.
Rarely the model. Models commoditise quickly. Your defensibility is far more likely to sit in your data, your domain knowledge, your distribution, ability to scale, your knowledge of the customer, and the sales.
Schedule your personalized consultation
Pricing
Languages
Book a Consultation
Schedule your personalized consultation