Build, Buy or Embedded AI Sourcing Strategies

1. Why This Topic Matters

Every AI system an organization uses arrives through one of a small number of sourcing paths: it is built in-house, bought as a standalone product or service, or it is embedded inside software and platforms the organization already owns. The sourcing decision is not a mere procurement detail. It determines who controls the model, where the data flows, which risks the organization owns outright versus shares with a vendor, and how much visibility the organization has into the system's behaviour. In other words, the sourcing strategy shapes the entire risk profile of the AI deployment before a single line of code runs.

For the ISACA Advanced in AI Risk (AAIR) exam, this topic sits within the AI Risk Governance and Framework Integration domain because sourcing is where governance meets reality. A well-written AI policy is meaningless if the organization has no idea that its CRM, HR suite, and productivity tools quietly shipped generative-AI features in their latest release. Equally, an organization that builds a model without a governed lifecycle has created a liability no vendor contract can offset. The exam expects you to recognise that sourcing is a governance decision, that each sourcing model carries a distinct risk and accountability pattern, and that oversight controls must be tailored to that pattern rather than applied uniformly.

Practically, this matters because:
• Regulatory obligations (for example, the EU AI Act's distinction between providers and deployers) differ depending on whether you built or acquired the system.
• Third-party and supply-chain risk is now the dominant AI risk vector for most enterprises, since the majority of AI capability is acquired rather than developed.
• Embedded AI is the single largest source of shadow AI and ungoverned AI inventory gaps.
• The sourcing choice drives cost, time-to-value, competitive differentiation, and the depth of due diligence required.

2. What It Is: The Three Sourcing Models

Build (In-House Development)
The organization designs, trains, fine-tunes, deploys, and maintains the AI system using its own data, infrastructure (or rented cloud compute), and talent. This includes training foundation models from scratch (rare and costly) and, far more commonly, fine-tuning or building retrieval-augmented applications on top of open-source or licensed base models. The defining characteristic is that the organization owns the full lifecycle and therefore owns the full stack of risks: data provenance, training integrity, model validation, bias testing, security hardening, monitoring, and retirement.

Typical drivers: proprietary data that confers competitive advantage, highly specific use cases, data residency or confidentiality constraints that forbid external processing, and the need for full explainability or control.

Risk signature: highest control, highest accountability, highest capability burden. Risks concentrate in talent gaps, immature MLOps, inadequate testing, model drift without monitoring, and the temptation to skip governance because the team is internal.

Buy (Acquired Standalone AI)
The organization procures a discrete AI product or service from a third party: an AI-as-a-Service API (such as a hosted large language model), a packaged AI application (a fraud detection platform, a resume-screening tool), or a managed model deployed on the organization's behalf. The organization becomes a deployer or user of someone else's model. Control over training data, model architecture, and update cadence rests substantially with the vendor.

Typical drivers: speed, lack of in-house expertise, access to frontier capability, lower upfront cost, and transfer of operational burden.

Risk signature: third-party and concentration risk, limited transparency (the black-box problem), data leakage through prompts or uploads, contractual gaps around liability and model changes, vendor lock-in, and the challenge of validating a model you cannot inspect. Accountability is shared contractually but never fully transferred; the deploying organization remains answerable to its regulators, customers, and board.

Embedded (AI Inside Existing Software)
AI features arrive as components of software the organization already uses: copilots in office suites, predictive scoring in ERP and CRM systems, automated transcription in collaboration tools, recommendation engines in e-commerce platforms, or AI-driven alerting in security products. The organization did not choose to acquire AI; it acquired a product that became AI-enabled, often through a routine update. This is the most pervasive and least visible sourcing model.

Typical drivers: usually none from the organization's side; the vendor drives adoption. Users may switch features on without any governance review.

Risk signature: inventory blind spots, shadow AI, unclear data flows (where does the copilot send the document?), features that activate by default, inability to opt out at a granular level, licensing terms that change silently, and governance frameworks that never considered these tools to be AI systems. Accountability is the murkiest here because nobody formally made an AI sourcing decision.

Hybrid and Partner Models
In practice many organizations combine approaches: buying a foundation model via API but building the application layer, retrieval pipeline, and guardrails; or co-developing with a vendor or systems integrator. The exam may present these as hybrid or partner options. The governance principle is the same: map each component to who controls it, and assign risk ownership accordingly.

3. How It Works: Decision Factors and Governance Mechanics

3.1 The Decision Framework
A disciplined sourcing decision evaluates several dimensions. The AAIR exam frequently tests whether you can identify which factor should dominate in a given scenario.

• Strategic differentiation: Is the AI capability core to competitive advantage? Core capabilities lean toward Build; commodity capabilities lean toward Buy or Embedded.
• Data sensitivity and residency: Highly sensitive or regulated data (health records, financial data, national security information) may prohibit external processing, pushing toward Build or private-hosted deployments.
• Internal capability and maturity: Does the organization have the data science, MLOps, and AI governance talent to sustain a built system over its lifecycle? Building without capability creates more risk than buying.
• Time to value and cost: Buying is typically faster and cheaper upfront; building incurs development and ongoing maintenance costs but may be cheaper at scale.
• Transparency and explainability requirements: High-risk or regulated use cases may demand model access that vendors will not provide.
• Regulatory role: Building may make the organization a provider under the EU AI Act with heavier obligations; buying makes it a deployer with its own, lighter but real, obligations.
• Vendor viability and concentration: Dependence on a single AI vendor for critical processes creates systemic risk.
• Control over change: Vendors update models without notice; a validated output today may differ tomorrow. Built systems allow controlled change management.

3.2 Risk Ownership and the Shared Responsibility Model
A central exam concept is that risk ownership shifts but accountability does not. Think of it as a spectrum:

• Build: The organization owns data risk, model risk, operational risk, and compliance risk directly.
• Buy: The vendor owns model development risk and (often) hosting security; the organization owns use-case risk, input data risk, output validation, human oversight, and the obligation to perform due diligence.
• Embedded: The vendor owns the model entirely; the organization owns the decision to enable the feature, the data it exposes, user behaviour, and the duty to discover and inventory the capability in the first place.

Governance frameworks such as the NIST AI Risk Management Framework (particularly the Govern and Map functions) and ISO/IEC 42001 require organizations to understand their AI supply chain and define roles and responsibilities across it. The AAIR exam expects you to connect sourcing to these framework requirements.

3.3 Governance Controls by Sourcing Model

Controls for Build:
• Formal AI development lifecycle (secure-by-design, privacy-by-design, fairness testing at each stage)
• Data governance: provenance, consent, lineage, quality, and bias assessment of training data
• Independent model validation and documentation (model cards, system cards)
• MLOps controls: version control, reproducibility, access management, drift monitoring
• Red-teaming and adversarial testing
• Clear model ownership and a decommissioning process

Controls for Buy:
• AI-specific third-party risk management: due diligence questionnaires covering training data, bias testing, security certifications, incident history
• Contractual provisions: data use and retention limits (no training on customer data), notification of material model changes, audit rights, liability allocation, exit and data portability terms, service levels for accuracy and availability
• Independent output testing on the organization's own data before and after deployment
• Data loss prevention and input filtering to prevent sensitive data leakage
• Vendor concentration analysis and contingency planning
• Ongoing monitoring of vendor performance and regulatory status

Controls for Embedded:
• AI inventory and discovery processes that scan existing software portfolios for AI features (the first and most important control)
• Policy requiring governance review before AI features in existing tools are enabled
• Configuration management: disable by default, enable by exception with documented approval
• Review of vendor update notes and licence changes for new AI functionality
• User awareness and acceptable-use training specifically addressing copilots and assistants
• Data classification rules defining what content may be processed by embedded assistants
• Inclusion of embedded AI in the organization's AI risk register and impact assessments

3.4 Integration With the Broader Governance Framework
Sourcing strategy should be formalised in an AI governance policy that mandates: a sourcing decision record for every AI use case, a central AI inventory regardless of source, risk tiering that applies the same impact criteria to built, bought, and embedded systems, and clear accountable owners. The sourcing decision should feed the AI impact assessment, which in turn determines required controls. This creates traceability from strategic choice to operational control, which is precisely the kind of integration the AAIR domain title describes.

4. How to Answer Exam Questions on This Topic

AAIR questions are scenario-based and typically ask for the best, most important, primary, or first action. For sourcing questions, apply this reasoning sequence:

Step 1: Identify the sourcing model in the scenario. Look for cue words. In-house data scientists, training data, fine-tuning, and proprietary model suggest Build. API, SaaS, vendor, licence, and subscription suggest Buy. New feature, software update, copilot, assistant inside an existing tool, and users discovered suggest Embedded.

Step 2: Determine what the question is really testing. Is it asking about risk identification, control selection, accountability, or the sourcing decision itself?

Step 3: Apply the dominant risk for that model. Build equals lifecycle and capability risk. Buy equals third-party, transparency, and contractual risk. Embedded equals inventory, visibility, and shadow AI risk.

Step 4: Choose the answer that preserves organizational accountability and governance integration. Eliminate options that transfer accountability entirely to a vendor, that rely solely on technical fixes without governance, or that address a secondary risk.

Step 5: Respect sequence. If the question asks what to do first, favour discovery, inventory, risk assessment, and governance alignment over implementing specific controls or signing contracts.

5. Exam Tips: Answering Questions on Build, Buy or Embedded AI Sourcing Strategies

Tip 1: Accountability never transfers. If an answer option implies that buying from a reputable vendor eliminates the organization's responsibility for bias, privacy, or regulatory compliance, it is wrong. The correct framing is shared responsibility with retained accountability.

Tip 2: Embedded AI questions almost always point to inventory and discovery. When a scenario describes AI features appearing in existing software, the best first step is to identify and inventory them and bring them under the governance framework, not to immediately disable them or renegotiate the contract.

Tip 3: For Buy scenarios, contracts and due diligence are the primary governance levers. Expect correct answers that reference data-use restrictions, change notification, audit rights, and independent testing of vendor outputs. Be wary of answers that assume the organization can inspect or modify the vendor's model.

Tip 4: For Build scenarios, lifecycle governance is the primary lever. Correct answers reference development standards, data governance, independent validation, and monitoring. Watch for the trap that internal development is inherently safer; it is only safer if capability and governance exist.

Tip 5: The sourcing decision should be risk-based and strategic, not purely cost-based. If a question asks what should primarily drive the build-versus-buy decision, the best answer typically balances strategic value, data sensitivity, internal capability, and risk appetite, not just lowest cost or fastest delivery.

Tip 6: Know the regulatory role shift. Building (or substantially modifying) an AI system may make the organization a provider with heavier obligations; buying or embedding generally makes it a deployer. Questions may test whether fine-tuning or rebranding a purchased model changes regulatory status.

Tip 7: Apply the same risk tiering regardless of source. An answer suggesting that embedded or purchased AI needs less rigorous impact assessment than built AI for the same high-risk use case is incorrect. The use case and impact, not the source, determine risk tier.

Tip 8: Watch for vendor concentration. If a scenario mentions critical processes depending on a single AI vendor, the correct risk is concentration or systemic dependency, and the control is contingency planning and exit strategy.

Tip 9: Prefer governance-integrated answers over isolated technical answers. ISACA exams favour answers that connect to policy, roles, inventory, and risk registers over those that propose a single tool or configuration change.

Tip 10: Read for the word that changes everything. Terms such as default-enabled, without approval, updated automatically, trained on our data, and no audit rights are signals pointing directly to the risk the question wants you to identify.

6. Worked Example

Scenario: A multinational insurer discovers that its productivity suite vendor enabled a generative-AI assistant in the latest release. Employees in the claims department have begun using it to summarise claimant medical documents. The AI governance committee was not consulted. Which of the following should the AI risk professional recommend first?

A. Negotiate contractual limits on the vendor's use of uploaded data
B. Immediately disable the assistant across the organization
C. Add the assistant to the AI inventory and conduct a risk and impact assessment of its use with claimant data
D. Train employees on prompt engineering best practices

Analysis: The cue words (vendor enabled, latest release, not consulted) identify an Embedded sourcing scenario. The dominant risk is a governance visibility gap combined with sensitive data exposure. Option B is a reaction without assessment and may be disproportionate. Option A is a valid Buy-type control but premature before the organization understands what is at stake. Option D addresses a secondary issue. Option C is correct: it brings the system under the governance framework and establishes the basis for all subsequent controls, consistent with the principle of discovery and assessment first.

7. Key Takeaways

• Sourcing is a governance decision that defines risk ownership, visibility, and regulatory role.
• Build maximises control and accountability burden; Buy introduces third-party, transparency, and contractual risk; Embedded creates inventory and shadow AI risk.
• Accountability for outcomes remains with the organization regardless of sourcing model.
• The same risk-tiering and impact assessment criteria must apply to all three models.
• Controls must be tailored: lifecycle governance for Build, third-party risk and contracts for Buy, discovery and configuration governance for Embedded.
• On the exam, identify the model, name its dominant risk, protect accountability, and respect the sequence of discovery, assessment, then control.