B3. Build, Buy, or Partner
The sourcing path for a use case, that is, building it yourself, buying a standard product, or implementing it with a partner, determines speed, cost, dependency, and data sovereignty.
What this chapter delivers: the decision-criteria matrix for choosing the sourcing path and the vendor questionnaire with eleven categories for structured selection. The frame is set by the policy decision from chapter B1 on whether competencies are built internally or bought; here it becomes concrete for each use case. To that end, the quick rule from chapter B2 (build differentiation yourself, buy standard functionality, bridge gaps with partners) is expanded into a robust decision.
Template: decision-criteria matrix
Each criterion is rated on a scale from 1 to 5. The table explains what the criterion concretely means, what high and low scores look like, and which direction a high score points to.
| Criterion | What it means | Example of a high score (5) | Example of a low score (1) | Tendency at high score |
|---|---|---|---|---|
| Differentiation | Does the use case create an advantage competitors can’t simply buy? “Standing out” means: the case rests on something of your own, usually exclusive data or unique process knowledge. | Fraud detection based on your own twenty years of claims history | A chatbot answering opening hours and delivery status | Build |
| Data sensitivity | How high is the protection need of the data processed? The more sensitive, the greater the risk of entrusting it to a third party. | Health data, credit data, trade secrets | Publicly available product catalogs | Build |
| Market availability | Does a mature standard solution already exist that demonstrably solves the problem? Rebuilding a solved problem is wasted budget. | Text recognition (OCR), transcription, translation | Industry-specific niche task with no product offering | Buy (at high availability) |
| Internal competence | Is the required expertise in-house or realistically buildable? Without your own capability, a build becomes a permanent construction site. | Experienced data-science team with production track record | Not a single person with ML experience | Build (only at high competence) |
| Time pressure | How quickly must the solution be ready? A build typically takes 6 to 18 months; a bought product is often usable in weeks. | A competitor is already live, customers demand the feature | Internal optimization with no deadline pressure | Buy or partner |
| Regulatory complexity | How high is the compliance effort, e.g., for a high-risk classification (see chapter B8)? An experienced partner can share documentation and evidence obligations. | High-risk application under Annex III with conformity assessment | Internal tool with minimal risk | Partner with regulatory experience |
| Integration depth | How tightly must the solution be embedded in core systems (ERP, CRM, policy systems)? Deep integration is often not achievable with standard products, or only at high cost. | Result must write back to your own core system in real time | Standalone tool without interfaces | Build |
| Long-term cost control | How important are predictable costs? Usage-based license and API costs grow with volume and can flip the business case (see chapter D2). | Mass process with millions of requests per year | Occasional internal use by a few people | Build |
Evaluation: if scores of 4 to 5 predominate, the picture favors in-house development. If low scores predominate alongside high time pressure, buying is the right choice. A mixed picture with high strategic importance but missing internal competence favors a partnership with a clear exit strategy. If the matrix is not filled in at all, the decision is made by gut feeling or vendor presentation, and that is exactly where the most expensive mistakes come from: bought solutions that can’t be integrated, or builds nobody has the competence for.
Vendor selection: questionnaire
Once buy or partner is the direction, the following catalog structures vendor selection. It covers eleven categories. Each question states why it is asked and what a poor answer looks like. The catalog is filled out for every vendor under comparison; the answers feed the comparison at the end of the chapter.
1. Company and references
Why this category: a vendor can convince functionally and still disappear from the market in two years. The solution would then need to be replaced at short notice, with all migration costs.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 1.1 | How long has the vendor been in the market, and how financially stable is it? | Young vendors without sustainable revenue vanish or get acquired, often with the product discontinued. Warning sign: under two years in the market and no verifiably paying customers. |
| 1.2 | Which reference customers exist in a comparable industry and size class? | A reference from the same industry proves that industry-specific requirements (domain knowledge, regulation) have already been solved. Warning sign: only logos on the website, no reference call possible. |
| 1.3 | What does the investor structure look like, and are there dependencies on individual backers? | A vendor depending on a single funding round may raise prices under pressure or be sold. Warning sign: funding running out with no visible path to profitability. |
2. Product and roadmap
Why this category: in sales presentations, the line between what works today and what is merely planned gets blurry. Whoever builds on announced features carries the vendor’s delivery risk.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 2.1 | Which features are available in production today, and which are still in development? | The purchase decision may only rest on features available today. Practice: try every feature mentioned in the meeting yourself in a test environment. |
| 2.2 | How transparent and binding is the product roadmap? | A public roadmap with history shows whether the vendor keeps commitments. Warning sign: roadmap only verbal or “under NDA”. |
| 2.3 | How often do interfaces change, and how are changes communicated? | Frequent breaking changes cause ongoing adaptation costs on your side. Good: versioned APIs with announced transition periods of at least 12 months. |
3. Data and data sovereignty
Why this category: using a vendor means your data leaves the house. What the vendor may do with it and what happens after contract end must be settled before signing; afterwards your negotiating position is gone.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 3.1 | Where is data processed and stored (region, data center)? | Data locations outside the EU can trigger GDPR transfer questions and may be impermissible for regulated industries. Ask concretely: subprocessors and support access count too. |
| 3.2 | Is customer data used to train the vendor’s models, and can this be excluded? | Otherwise your business data can indirectly flow into models that are also available to competitors. Good: a contractually guaranteed exclusion, not just an opt-out setting. |
| 3.3 | How is data deleted after contract end, and is export in open formats possible? | Without export capability, the data accumulated over years (configurations, feedback, history) is lost on switching. Warning sign: export only in proprietary formats or at extra cost. |
4. Security
Why this category: the vendor becomes part of your attack surface. A security gap at the vendor is a security gap in your own company (see chapter B9).
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 4.1 | Which certifications exist (e.g., ISO 27001), and how current are they? | Certificates prove audited baseline processes. Warning sign: expired certificates or certificates covering only part of the company. |
| 4.2 | How are access control, encryption, and key management implemented? | Decides whether vendor staff can see your data in plain text. Good: encryption with customer-controlled keys, documented authorization concept. |
| 4.3 | How are security incidents handled, and within what timeframe is notification given? | Your own 72-hour GDPR notification deadline only holds if the vendor itself reports quickly. Fix contractually: notification within a maximum of 24 to 48 hours. |
5. Regulation and compliance
Why this category: when using bought AI, your company remains the deployer with its own obligations under the EU AI Act. Without the vendor’s cooperation, those obligations cannot be met (see chapter B8).
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 5.1 | What role does the vendor take under the EU AI Act, and does it support your deployer obligations? | Deployers need instructions for use, log access, and information on system limits from the vendor. Warning sign: the vendor cannot state the risk classification of its own product. |
| 5.2 | Are technical documentation and evidence provided for high-risk classifications? | For high-risk use cases, this evidence is mandatory. Without it, the product is effectively unusable for the use case, no matter how well it works. |
| 5.3 | Is there a GDPR data-processing agreement, and does it cover all processing steps? | Without a complete DPA, processing personal data is unlawful. Check: are AI-specific steps such as model improvement and telemetry covered? |
6. Agentic AI capabilities
Why this category: as soon as the product acts autonomously (sends emails, changes records, triggers bookings), stricter requirements apply. An agent with overly broad rights can cause real damage (see chapter B9).
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 6.1 | Which tools and actions can the vendor’s agent execute, and how are they restricted? | It must be configurable which actions the agent may execute at all (least privilege). Warning sign: rights can only be toggled wholesale. |
| 6.2 | Is a human-in-the-loop mechanism provided and configurable for consequential actions? | Irreversible actions such as payments or deletions need human approval. Check: can approval be required per action type? |
| 6.3 | How complete and exportable is the logging of agent actions? | Without a gapless, exportable log, what the agent did cannot be reconstructed in case of damage, and audit obligations cannot be met. |
7. Integration and interfaces
Why this category: value only materializes once the solution is embedded in your processes. Integration costs not infrequently exceed license costs by a multiple.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 7.1 | Which standard interfaces (APIs) exist to common core systems (ERP, CRM, DWH)? | Ready-made connectors save months of integration work. Check: does the connector exist for your system version, not just for the product in general? |
| 7.2 | How much effort is the connection to your existing data platform? | If data must be transferred manually or via detours, error sources and duplicate storage emerge. Good: automated, logged connection to your platform (see chapter B5). |
| 7.3 | Does the vendor support open standards, or does it require proprietary formats? | Proprietary formats deepen lock-in: every invested hour binds you more strongly to the vendor. Open standards keep the switching path open. |
8. Operations and service level
Why this category: as soon as a business process depends on the solution, the vendor’s availability becomes your availability.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 8.1 | What availability is contractually guaranteed, and how is it measured? | A promise without a measurement method and without penalties is worthless. Check: does the promise cover the full function or only individual components? |
| 8.2 | What support hours and escalation paths exist? | If your process runs around the clock, business-hours support is not enough. Warning sign: support only via ticket with no committed response time. |
| 8.3 | How transparent is monitoring, and do you get insight into operational metrics? | Without your own view of outages and response times, you notice problems only through user complaints. Good: status page plus API access to metrics. |
9. Scalability and performance
Why this category: a product that convinces in a test with 100 requests can collapse or become unaffordable at 100,000 requests per day.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 9.1 | How does performance behave as request volume increases? | Response times must stay stable under load. Practice: agree on a load test with a realistic target volume before signing. |
| 9.2 | Are there capacity limits or quotas, and how are they communicated? | Silent throttling (rate limits) can slow your process unnoticed. Limits must be documented and breaches actively reported. |
| 9.3 | How are load spikes handled, and what cost-control mechanisms exist? | With usage-based pricing, a load spike (or a bug in your own integration) can multiply the monthly bill. Good: configurable budget limits with alerts (see chapter D2). |
10. Commercial terms
Why this category: the pricing model determines long-term economics more than the entry price. The exit terms determine your negotiating power for all future pricing rounds.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 10.1 | How is the pricing model structured (usage, seats, quotas), and how transparent is billing? | The model must match your usage profile: seat pricing penalizes broad use, usage pricing penalizes high volumes. The bill must be traceable per use case. |
| 10.2 | What minimum terms and notice periods apply? | Long lock-in plus an immature product is the most expensive combination. Warning sign: a multi-year contract as the condition for the introductory discount. |
| 10.3 | What exit terms exist: data export, transition support, cost of switching? | Whoever cannot credibly switch negotiates future price increases from the weaker position. Negotiate exit terms before signing, not when needed. |
11. Sustainability and responsibility
Why this category: your own sustainability goals and ethics guidelines (see chapter B10) also apply to bought solutions. What the vendor does is attributed to your company, by customers and oversight bodies alike.
| No. | Question | Why it matters, and what to look for |
|---|---|---|
| 11.1 | Is information on energy consumption or the CO2 footprint of model usage provided? | Without this information, your own sustainability reporting stays incomplete at this point. Good: consumption figures per request or per quota. |
| 11.2 | Which principles of fairness and responsible AI development does the vendor follow? | Discriminatory results from a bought model hit your company as the deployer. Check: are there published principles and documented bias tests? |
| 11.3 | How does the vendor handle bias and quality issues in its own models, and how transparently is this reported? | Every model has weaknesses. What matters is whether the vendor discloses and fixes them. Warning sign: “Our model has no bias problem” as the answer. |
Template: vendor comparison
Each category receives a rating from 1 (weak) to 5 (strong), based on the answers from the questionnaire. Knockout criteria (such as a missing DPA or no data export) are marked separately and lead to exclusion regardless of the total.
| Category | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Company and references | |||
| Product and roadmap | |||
| Data and data sovereignty | |||
| Security | |||
| Regulation and compliance | |||
| Agentic AI capabilities | |||
| Integration and interfaces | |||
| Operations and service level | |||
| Scalability and performance | |||
| Commercial terms | |||
| Sustainability and responsibility | |||
| Total / knockout criteria |
Checklist: build-buy-partner decision ready
The checklist verifies that the sourcing decision is fully secured, from the matrix to the contract points:
- Decision-criteria matrix completed for the use case
- Sourcing path documented with justification, not just decided
- For buy or partner: questionnaire answered for at least two vendors
- Vendor comparison rated per category, knockout criteria marked separately
- Knockout criteria defined and checked (DPA, data export, training exclusion)
- Data location clarified, including sub-processors and support access
- For agentic capabilities: tool permissions constrainable, human-in-the-loop configurable, logging exportable
- Availability, support hours, and incident notification deadline contractually assured
- Pricing model checked against your own usage profile, cost limits and alerts agreed
- Vendor’s sustainability and fairness principles reviewed, bias tests documented
- Exit strategy and data export contractually secured
- Regulatory role split (provider/deployer) clarified
- Result recorded in the business case (see chapter B2)