Hire an AI engineer: permanent, contract, team or build

These are the questions I would want settled before anyone starts, whichever route you take. The numbers in brackets point to the sources at the foot of the page. The table describes each route as the market sells it; what 1AYM offers comes after the decision guide.

Employ someone when the work is permanent and central: an AI capability your product depends on, which somebody has to own, improve and answer for over years. The knowledge stays in the company for as long as the person does, and in both the UK and the US the employer owns the copyright in work an employee makes as part of their job, unless you agree otherwise [7, 9, 10].

It is also the route with the most fixed cost, and salary is only the start of it. On top of salary, the employer pays payroll taxes and benefits. In the UK, for the 2026 to 2027 tax year, an employer pays National Insurance at 15% on an employee's earnings above £5,000 a year, and an employer with an annual pay bill over £3 million pays Apprenticeship Levy at 0.5% of it, less a £15,000 allowance [3]. UK automatic enrolment adds at least 3% of qualifying earnings into a workplace pension; in most schemes those are earnings between £6,240 and £50,270 a year [4]. In the US, the employer pays its own share of Social Security and Medicare taxes, and federal unemployment tax from its own funds [5]. Then add any recruitment fee, equipment, and the time a new hire takes to learn your systems.

The start date depends on the search and on the notice period the candidate owes their current employer, neither of which you fully control. Hire first for the role that will own the work once any outside help has gone. I would not make a first AI hire with nobody senior to review their work: that hire carries the same single-person risk as a contractor, with a longer exit.

A contractor gives you one person's skill for a defined period, often through their own company. You find, interview and manage them, and if they leave, replacing them is your job too. Their rate pays for their time. Recruitment, onboarding, review and cover are still yours to provide.

Settle two things in the contract before the first day. The first is copyright, because it is the one you cannot fix cheaply once the contractor has gone. UK law treats a computer program as a literary work [6], and in both the UK and the US the author owns the copyright first unless they are an employee working in the course of their job [7, 9, 10]. A contractor is not your employee, so the code is theirs until they transfer it to you, and a transfer of copyright only takes effect in writing, signed by the owner or on their behalf [8, 10]. The second is handover: what they leave behind, in what form, and who checks it before their last day.

HMRC in the UK and the IRS in the US each publish tests for whether a contractor counts as self-employed for tax, and both look at the whole working relationship, not only the contract [1, 2]; this is not legal or tax advice.

Here a supplier provides the people: one engineer or several, on a contract for a period, charged for their time. The supplier does the finding and matching and replaces someone who is not working out, so the roles do not wait on your own hiring round. Buyers often call this staff augmentation. Your own leads usually direct the work, and that is what separates it from outsourcing, where the supplier directs the people and delivers a service.

It works best when you already have technical leads and a backlog ready to work on. Done well, it adds senior hands to a team that already knows what it is building, without waiting on a hiring round. What decides whether it is done well is the supplier's bar: how it vets people, who reviews their work, and how quickly it replaces someone who is not the right fit. Ask about all three before you sign.

When the output can be written down, buy the output. A fixed-scope build is priced against a deliverable, with acceptance criteria in the statement of work, and the supplier decides who does the work and manages them. You direct what gets built, not how the supplier's people spend their day.

It is the wrong buy when the work cannot yet be defined, because a price against a vague output is either padded or wrong. That is what a short feasibility sprint is for: it settles what to build, so the build can then be priced against an output.

Start from the situation you are in, not from the route. The table gives a first answer for four situations, one for each column in the comparison above.

Two situations fit none of the four columns cleanly. If nobody owns the architecture or the technical decisions, find someone to take those decisions now and write them down for the people you hire later, or every route inherits the gap. If you cannot yet say what to build, a short fixed-scope feasibility sprint turns the idea into an output that can be staffed or priced.

The routes also combine. A fixed-scope sprint can define the work, contracted capacity can build it, and a permanent hire can own it afterwards. So decide first who will own the system in two years' time, then choose the routes that hand it to them.

Where the work can be written down, we build it on a fixed scope, priced against an output rather than time, and the build can start within a day of the scope being signed. If you cannot yet say what to build, our AI opportunity and feasibility sprint settles it, typically in two to four weeks, and a fixed-scope architecture and production build then ships it. Where the contract needs it, copyright in the deliverables is assigned to you.

If you already have a scoped job and need people to deliver it, we can resource it from the collective of associates who work with 1AYM, held to the same standard as the rest of the firm, on a contract from three months. That is the staffed-team route from the table above, and it suits a team whose leads already know what they are building. You direct the work day to day, in your backlog and your stand-ups. One of our architects reviews it each week, and a role can be changed or added under the same contract.

When what is missing is someone to own the architecture and the build rather than extra hands, a retained AI implementation team is the closer fit. It holds the architecture and the vendor and model decisions, builds alongside your engineers and hands the platform over to them. And if the honest answer for you is a permanent hire, hire. The comparison above does not change because we sell two of its columns.