Finding AI capability targets without buying a supplier dependency

By Joash Boyton, founder, owner and CEO of Acquiry

Sponsored educational article by Acquiry.

To find an acquisition target with a useful AI capability, define the business outcome the buyer needs and identify what the target actually controls. Break the capability into product, code, data rights, people, contracts and third-party services. Then translate the required control and continuity into search criteria. AI branding, an impressive demonstration or access to a model does not by itself establish that the buyer will acquire the capability it wants.

The objective is not to eliminate every supplier. A target can use third-party technology and still contribute valuable product design, workflow knowledge, customer relationships or operating capability. The buyer needs to understand what it is acquiring, what remains dependent on others and whether those dependencies fit its strategy. This guide offers a commercial search framework, with technical and legal conclusions reserved for appropriately qualified reviewers.

Define the job before the technology category

Start with the task the buyer wants to perform better. Identify the user, the input, the required output and the decision or action that follows. Explain what is unsatisfactory about the current process. Avoid a search instruction that asks for an AI company without defining the capability the acquisition should provide. That instruction leaves too much room for attractive but unrelated products.

Describe the operating context in which the capability must work. Is the intended use internal or customer facing? Does it support a human decision, prepare material for review or perform an authorised action? Which failures would matter to the buyer? These questions help determine what evidence is needed and which specialists should help formulate the brief before targets are researched.

Keep the desired outcome separate from a preferred implementation. The buyer may believe a particular model or technical approach is necessary, but that assumption should be tested by its technical team. A target using a different implementation could serve the objective, while one using familiar technology might not. The search should preserve the reason for the requirement rather than matching a fashionable category label.

Decide what control the buyer needs

Ask which parts of the capability the buyer wants to control after an acquisition. It may want authority over the product roadmap, access to relevant expertise, the ability to operate in a particular environment or continuity of a customer workflow. These are different requirements. Translate each into an evidence question rather than using ownership as a single undifferentiated label.

The buyer should also identify what dependence it is prepared to retain. A supplier relationship may be acceptable if its terms, operational role and alternatives fit the intended use. Another dependency may undermine the acquisition rationale if the buyer specifically wants control of that component. The answer depends on the strategy, not on a universal preference for internally developed technology.

Use a control statement in the brief. For a hypothetical buyer, it might say that the target must provide a product workflow the buyer can continue developing, with rights and operating arrangements that qualified advisers consider suitable for the intended deployment. That statement still needs more detail, but it is more useful than an unsupported request for proprietary AI.

Inventory the product capability

Describe what the customer or internal user experiences. Which task does the product perform, what work remains with the user and how is the output used? Ask for an authorised demonstration that shows the relevant workflow, including review and exception handling. A polished endpoint can hide steps that matter to the operating model, so follow the task from input to outcome.

Identify what distinguishes the product from the underlying service it uses. The target may contribute workflow design, domain-specific preparation, evaluation, integration or customer support. Those contributions should be described concretely and tested against the buyer's objective. Do not dismiss them simply because the target relies on an external model, and do not assume they are valuable merely because they surround one.

For search purposes, record the product contribution as a hypothesis supported by available evidence. Public descriptions can indicate relevance, while an owner discussion may clarify the workflow. Technical review should determine conclusions that require deeper access. Keep the stages separate so that a useful demonstration does not become an unsupported claim about ownership, performance or continuity.

Identify the code and development responsibilities

Ask which software components are developed and maintained by the target, which are supplied by others and which have a mixed origin. The question is an inventory request, not a legal conclusion. The buyer's technical and legal reviewers should determine what evidence they need about rights, licences, contributor arrangements and ongoing obligations for the intended transaction and use.

Also identify who can change the components that matter to the acquisition thesis. A target may operate a product while relying on an external party for a critical part of its development. That arrangement could be workable, but the buyer should understand the responsibility and continuity questions. The search brief can flag these issues without claiming that all development must be performed in-house.

Ask how important knowledge is documented and reviewed. Which people understand the architecture, evaluation process and operational incidents? What would the buyer need to continue development responsibly? These questions help distinguish acquiring a maintainable capability from acquiring a product whose future depends on arrangements the buyer has not yet assessed.

Map data by purpose and rights question

Create an inventory of the information the capability uses. Separate material used during development, material used during operation, customer-provided information, evaluation material and outputs retained for later use. The categories help the buyer ask precise questions. They do not determine the legal treatment of the information, which requires specialist review of the actual facts and applicable requirements.

For each category, ask where it comes from, why it is needed and what rights or permissions support the intended use. Identify who can provide the relevant agreements or other evidence through an authorised process. Do not assume that possessing a dataset establishes the right to use it for every purpose or to transfer it in every transaction structure.

The search criterion should reflect the buyer's actual requirement. If the acquisition thesis depends on a particular data resource, make that dependency explicit and identify the verification needed before progression. If the product can provide the desired value without acquiring that resource, the buyer may have more options. The adviser should not let a broad data advantage claim settle the question.

Understand the people contribution

Ask which capabilities sit with the team rather than in a document or code repository. The buyer may value product judgment, domain expertise, evaluation design, engineering or customer implementation knowledge. Describe the contribution and identify how it relates to the desired outcome. Avoid treating a team label as proof that the relevant knowledge exists or can be retained.

The buyer should decide how the team would work within its own organisation. Who would lead it, what resources would it need and what responsibilities would remain with existing staff? These are acquisition-planning questions, not promises that particular people will join or remain. Employment and contractual matters require the appropriate professional review and agreement.

At the search stage, identify whether the buyer seeks a business that can operate independently or a capability that depends on close integration with its own team. The distinction changes the target profile. A strong technical group may not bring the product, customer or operating structure the buyer expects, while an established product business may not provide the specific expertise the buyer wants to acquire.

Inspect the contract map before assuming continuity

List the relationships on which the proposed capability depends: customers, model providers, infrastructure suppliers, development partners and other relevant counterparties. Ask who holds each agreement and which aspects need review for the buyer's intended transaction and operating plan. The purpose is to direct specialist work, not to infer that a contract will transfer or continue unchanged.

Identify any part of the acquisition rationale that assumes a particular commercial permission. The buyer may expect to serve a new customer group, deploy in a different setting or change how the product is offered. Ask counsel and the relevant commercial owners to assess whether the agreements support that plan. A product operating successfully today does not answer every question about a different future use.

For initial qualification, an approved summary of the contractual dependencies may be sufficient to identify the next decision. Detailed documents should be requested through the agreed information process. Keep unresolved terms visible rather than allowing a supplier's familiar name or the target's confidence to substitute for a review of the applicable arrangement.

Identify model provider dependence

Ask which model services or model components support the relevant workflow and what role each plays. Does the target use one provider, several alternatives or a combination of approaches? Which parts of the product would need work if the current arrangement changed? These are technical and commercial questions to investigate, not an assumption that one configuration is inherently superior.

Clarify what the target contributes beyond access to the model. It might organise the workflow, prepare inputs, evaluate outputs, manage user interactions or support deployment. Ask for evidence tied to the buyer's task. If the acquisition thesis specifically requires control of a model component, identify the evidence needed to establish that control rather than inferring it from the product's branding.

A supplier dependency can be acceptable when it is understood and consistent with the buyer's objective. It becomes a problem for selection when the search brief assumes ownership of something the target does not control, or when continuity depends on an unexamined arrangement. The next step is to investigate and classify the dependency, not to make a blanket judgment about all externally supplied models.

Include infrastructure and operational services

Map the services required to deliver the product, including relevant hosting, storage, identity, monitoring and other operating components. Ask the technical team which of these materially affect the buyer's intended deployment. The search should identify consequential dependencies without turning an early commercial screen into a full infrastructure audit.

Discuss who operates the system and handles incidents. Which activities are performed by the target's team, a customer or an external provider? What information does the buyer need to understand the responsibility split? If the acquisition thesis assumes a different operating environment, identify the changes that require investigation. Do not describe relocation or substitution as straightforward without appropriate technical evidence.

Also ask how the target learns when performance changes or a component stops behaving as expected. The buyer needs to understand the operating process surrounding the capability, not only the demonstration under favourable conditions. The relevant reviewers should determine what records and tests are necessary to assess that process for the buyer's use case.

Test substitutability with a specific question

A claim that a supplier can be replaced should be tied to the task, evidence and work involved. Ask which component would change, what would need to be rebuilt or retested and who would perform the work. The buyer should not accept a general statement that the system is provider independent without understanding what that means in practice.

A proportionate evaluation might ask the technical team to assess a bounded alternative using approved material. The objective is to test the particular continuity assumption, not to reproduce the whole product during initial screening. Define the conditions and success criteria before reviewing the result. A different output or user experience may matter even if the replacement is technically connected.

Record what the test establishes and what remains untested. A demonstration of one alternative may provide useful evidence without proving that every provider can be substituted or every operating condition is covered. The search decision should reflect that scope. Where substitution is essential to the acquisition thesis, insufficient evidence may justify a pause or a different target profile.

Evaluate performance against the intended task

Ask the buyer's technical and domain specialists to define what useful performance means for the actual workflow. The evaluation should reflect the input types, required outputs and consequences of errors that matter to the buyer. A general demonstration or a headline benchmark may not answer those questions. The origination brief should identify the performance assumptions that determine apparent fit.

Use authorised evaluation material and document its limitations. The buyer may need to distinguish a demonstration prepared for the meeting from a broader evaluation of ordinary and difficult cases. Ask who selected the examples and what happens when the capability produces an unsuitable result. These questions help the buyer determine what further review is warranted without overstating the evidence available at the search stage.

NIST describes its AI Risk Management Framework as a voluntary resource for incorporating trustworthiness considerations into AI design, development, use and evaluation. Its generative AI profile provides additional risk-management guidance. These resources can inform specialist questions, but they do not certify a target, establish transaction suitability or replace an evaluation designed for the buyer's particular use.

Account for the human work in the capability

Follow the workflow beyond the generated output. Who checks it, corrects it, approves it or acts on it? Ask whether the target's offering includes human review or other services that the buyer would need to maintain. The answer affects the operating capability being acquired and the resources required to deliver it. Do not assume a task is fully automated because the customer sees an AI interface.

Identify exception handling as well as ordinary operation. If a user cannot obtain a useful result, what happens next? Is support provided by a specialist team, the founder or the customer's staff? These questions should inform the target profile when the buyer has a clear preference or constraint about the service model.

A human-supported product can be a suitable acquisition if it matches the buyer's objective. The issue is whether the business is described accurately and the buyer can support the work. If the thesis assumes that human involvement will be reduced, identify the evidence needed to test that proposal. Treat the change as a hypothesis requiring review rather than a benefit already established by the acquisition.

Examine operating economics without inventing a forecast

Ask what activities drive the cost of delivering the relevant task. The finance and technical teams may need to understand usage, supplier arrangements, human review and support. The search partner can identify the questions and request authorised summaries, but should not present a screening estimate as a verified financial conclusion.

Test the acquisition rationale against changes in the workload that matter to the buyer. A different customer use pattern or a more demanding task may require a different operating assessment. Use clearly labelled scenarios with assumptions supplied and reviewed by the appropriate team. Avoid borrowing a generic industry benchmark when the target's actual operating model is the issue.

The useful output is a list of economic assumptions that need evidence before the buyer relies on the capability. It may show that a target deserves further investigation, that the intended use requires a revised plan or that the acquisition thesis is not yet supported. This guide does not prescribe valuation, investment returns or a universal cost threshold.

Translate the inventory into searchable criteria

Turn the capability inventory into criteria that an origination team can investigate. Specify the task served, user context, product contribution, required operating model and critical ownership or continuity questions. Mark which criteria can be assessed initially from public information and which require an authorised owner discussion. Do not ask researchers to certify facts they cannot reasonably establish at that stage.

For each criterion, explain the strategic reason. A researcher who understands why continuity matters can identify relevant evidence and sensible adjacencies. A researcher given only a list of AI keywords may include businesses that share terminology while providing a different capability. The brief should help the team distinguish meaningful relevance from branding similarity.

Use a clear unresolved category. A company can appear relevant while a critical rights or dependency question remains open. The next step should identify the evidence and reviewer needed to resolve that question. Avoid forcing every company into a confident fit or rejection before the necessary information is available, while also avoiding a growing list of indefinite possibilities with no next action.

Keep evidence requests proportional to the decision

Before requesting technical or contractual material, state the decision it will support. An early question may be answered by an approved capability summary or dependency map. A later decision may require specialist access to documents, code or operational evidence. Agree the appropriate confidentiality, access and review process with the relevant advisers and information owners.

Maintain a distinction between management statements, observed demonstrations and independently reviewed conclusions. Record the date and scope of each item. A statement that the target controls a component should lead to an appropriate evidence request, not be repeated as a legal conclusion. The same discipline applies to claims about performance, portability and customer rights.

The origination partner's role is to help the buyer find relevant companies and organise informed conversations within scope. Technical auditors, counsel and other specialists determine the conclusions that require their expertise. The buyer should appoint those specialists at the stage when their answer affects the search, rather than assuming every important question can wait until a preferred target has been selected.

Compare alternative capability theses

The buyer may be seeking a product business, a team, a data-dependent capability or an operating process. Each thesis requires a different target profile. A product acquisition might emphasise a customer workflow and continuing development. A team-focused thesis might emphasise specific expertise and the plan for working within the buyer. A data-dependent thesis requires careful attention to the rights and continuity questions that support the intended use.

Do not combine these rationales merely because a target presents all of them in a pitch. Identify which contribution is essential and which is optional. If the essential contribution cannot be substantiated, secondary attractions should not automatically rescue the thesis. The buyer can decide to pursue a different rationale, but that should be an explicit change with its own evidence requirements.

Also consider whether the desired capability requires ownership of a business at all. A supplier arrangement, partnership or internal development effort may address the objective differently. The comparison should use the buyer's actual needs for control, continuity and operating capacity. This is not an assumption that acquisition is faster or better; it is a way to prevent an acquisition search from becoming a foregone conclusion.

Work through a hypothetical dependency screen

Consider a hypothetical buyer seeking a tool that helps employees prepare a recurring decision document. The buyer wants a product workflow it can develop over time and operate under arrangements suitable for its intended use. It has not decided that it needs to own the underlying model. This fictional example contains no actual target or client information.

The first fictional target provides a well-organised workflow around an external model service. It has a product team and documented review steps, but supplier terms and alternative arrangements need investigation. The second describes its technology as proprietary, yet the available material does not explain which components it controls or how the product is operated. The third offers a specialist team with relevant expertise but no established product matching the buyer's workflow.

The first may deserve further investigation because its product contribution appears relevant and its dependency can be examined. The second should not receive a stronger classification merely because of its ownership language. The third may support a team-acquisition thesis, but that differs from acquiring an existing product. The buyer should record the distinction instead of assuming that all three are interchangeable AI targets.

The next requests should be specific. For the first, the buyer could seek an approved dependency inventory and specialist review of the relevant arrangements. For the second, it could ask for a component-level explanation and supporting evidence. For the third, it should decide whether it is willing to undertake the product-building work that its original thesis did not include.

The purpose of the screen is to identify what the buyer would actually acquire and what it must still verify. It does not rank the fictional businesses or predict their value. A different buyer with a different objective could make a different choice based on the same facts.

Change the control requirement and review the result

Suppose a second hypothetical buyer needs the capability to operate in a setting with different deployment requirements. The first target's current supplier arrangement may then raise a critical unresolved question, even if it suited the original buyer's proposed use. The buyer should ask qualified reviewers whether the requirement can be met and what changes would be necessary before treating the target as a fit.

Alternatively, a buyer seeking specialist expertise for an existing internal product might find the team-focused target more relevant. It would need to assess the people contribution and operating plan rather than judging the target against a product-acquisition brief. These variations show why ownership and dependency must be interpreted in relation to the acquisition objective.

The search partner should preserve the buyer-specific reasoning. A target that fits one control requirement does not automatically fit another. When the buyer changes its intended deployment or operating model, revisit the criteria and evidence rather than relying on a classification made under different assumptions.

Build the capability ownership and search worksheet

Use the following fields to create a brief that a researcher, an owner and a specialist can interpret consistently. For each field, record the current evidence, the unresolved question, the reviewer and the decision affected. The worksheet is a proposed commercial tool, not an AI audit certification or a legal opinion.

Task and operating context

State the user, input, output and action supported. Describe the buyer's intended setting and the failures that would matter. Identify the internal sponsor responsible for confirming the need. This field prevents the search from being driven by a broad technology label disconnected from a useful business outcome.

Product contribution

Describe the workflow and experience the target appears to provide. Identify what the buyer expects to acquire beyond access to an external service. Record which parts have been observed and which remain management statements. The contribution should be concrete enough to guide a demonstration or a focused next question.

Code and development control

Identify the components requiring ownership or suitable rights for the buyer's plan. Record who develops and maintains them and what evidence technical and legal reviewers require. Do not infer ownership from possession of code or from a proprietary label. The field should route a precise question to the appropriate specialist.

Data and use permissions

List the information categories essential to the capability and their purposes. Identify the source, relevant arrangements and proposed use that need review. Mark dependencies central to the thesis. The objective is to understand the evidence required, not to make a generic declaration that a dataset is transferable or suitable for every use.

People and operating work

Describe the expertise, support and human review the buyer expects to retain. Identify the responsibilities that need a transition or ongoing operating plan. Keep assumptions about individual participation separate from verified commitments. The search criteria should reflect the team and service model the buyer is actually prepared to support.

Suppliers and continuity

Map the model, infrastructure and other relationships that matter to the capability. Record the proposed continuity assumptions and any substitution claim requiring evidence. Explain why each dependency is acceptable, unacceptable or unresolved for the buyer's objective. Avoid treating the mere presence of an external supplier as a complete investment judgment.

Performance and economics evidence

Identify the task-specific evaluation and operating assumptions that need review. Record the test scope, material limitations and responsible technical or finance specialist. Keep a demonstration distinct from a broader conclusion. The buyer should know what the available evidence establishes before relying on it in a transaction decision.

Search decision and next verification

Classify the company as apparent fit, apparent mismatch or unresolved against the actual brief. State the next evidence request and who can authorise it. If the rationale changes, identify the decision-maker who must approve the new thesis. The worksheet should result in an actionable step rather than an indefinite list of interesting AI companies.

Where Acquiry fits

Acquiry helps buyers translate acquisition objectives into target profiles, research companies and approach owners, including businesses not openly for sale. Its software coverage provides a relevant context for searches involving product, workflow and technology capabilities. For an AI-related search, the useful starting point is a precise capability brief with the ownership and continuity questions visible.

Origination support should be coordinated with the buyer's technical, legal and operating specialists. The adviser can help organise target research and owner discussions; it should not be treated as providing an AI audit or legal conclusion unless that separate capability and scope have been expressly established. A buyer whose main uncertainty concerns technical feasibility may need specialist work before a broad search is useful.

The acquisition decision should follow the capability the buyer can substantiate and operate, not the prominence of AI language in the target's presentation. Clear target criteria help the buyer and its adviser find relevant conversations while keeping the consequential questions available for proper review.

Frequently asked questions

Does using an external model make a target unsuitable?

No general conclusion follows from that fact alone. Ask what the target contributes, what the buyer needs to control and whether the supplier arrangement fits the intended use. Product design, workflow knowledge and operating capability may still be relevant. The dependency needs investigation when it affects continuity or contradicts the acquisition thesis. The buyer should evaluate the actual arrangement rather than apply a blanket rule.

What does proprietary AI mean in a search brief?

The phrase is too broad to serve as a complete criterion. Specify the component, the control or rights required and the evidence needed to establish them. The buyer might mean a model component, application code, a workflow or a particular data-dependent capability. Those are different questions. Ask the technical and legal teams to translate the intended meaning into a usable requirement.

Can a demonstration establish the capability the buyer wants?

It can provide useful evidence about a defined task under observed conditions. It does not answer every question about rights, continuity, performance across other cases or operating requirements. Record what was demonstrated and what remains unresolved. Design further evaluation around the buyer's intended use with the appropriate specialists rather than treating presentation quality as a substitute for evidence.

Should data be a hard requirement for every AI acquisition?

Only when a particular data resource or use is essential to the buyer's thesis. Define the purpose and ask qualified reviewers what rights and evidence are needed. Some acquisition objectives may focus on product workflow or team capability instead. The search should not require a broadly described data advantage simply because it sounds attractive; it should explain why that resource matters to the intended outcome.

When should the buyer test an alternative supplier?

When substitutability materially affects the acquisition rationale or continuity requirement. Define the component and task to be tested, the authorised material and the criteria for review. A bounded evaluation may answer the immediate question without recreating the whole product. Record its limitations and avoid turning one successful test into a universal claim about portability.

What is the first useful instruction to an origination adviser?

Describe the business task, the capability the buyer wants to acquire and the control it needs. Add the critical dependencies that require verification and the specialists who will assess them. Ask the adviser to map companies against those criteria and distinguish apparent fit from unresolved evidence. That instruction is more actionable than a request for AI businesses with no defined purpose.

Make the next acquisition decision

Before searching, agree which capability is essential, which supplier dependencies are acceptable and which questions must be resolved before progression. Use the inventory to guide research, owner conversations and specialist review. Revise the brief when evidence changes the buyer's understanding, rather than forcing every interesting company into the original thesis.

A useful AI acquisition search makes ownership and dependence explicit. It helps the buyer distinguish a product it can develop, expertise it can use and relationships it must continue managing. The aim is a capability that fits the intended business outcome, supported by evidence and a workable operating plan, rather than an acquisition justified by a technology label.

Sources and further reading

• Acquiry buy-side acquisition process: https://www.acquiry.com/acquisitions/
• Acquiry software coverage: https://www.acquiry.com/saas-acquisitions/
• NIST AI Risk Management Framework and generative AI profile overview: https://www.nist.gov/itl/ai-risk-management-framework

About the author: Joash Boyton is founder, owner and CEO of Acquiry, a Melbourne-based M&A advisory firm focused on buy-side acquisition origination. The firm helps buyers define target criteria, identify off-market businesses and qualify owner discussions. acquiry.com.