Product Judgment, Build vs Buy, Governance, and Current Regulation

Mission

By the end, you can decide whether an agent should exist, compare build and buy options with workload evidence, assign governance to accountable people, and perform a careful first-pass regulatory screen without declaring every agent “high-risk” or treating a dated summary as legal advice.

Prerequisites: Chapter 7.1 and a capstone with a written task contract. Build artifact: a decision record, supplier evidence matrix, governance file, and dated regulatory screen. Time: 90-120 minutes.

Before you read: Predict → Commit → Connect

Two vendors demonstrate support agents. Vendor A completes 18 polished demo tickets. Vendor B exposes fewer features but provides data-flow diagrams, configurable retention, audit exports, version pinning, incident terms, and your evaluation set can run before purchase.

Which one is lower risk and better value? Write your answer and the evidence that could change it. If your reasoning depends on a popularity ranking, a promised percentage return, or “enterprise-grade” language, mark that claim unverified.

Product judgment comes before architecture

The first question is not “Which agent framework?” It is “Which user outcome deserves a system, and what is the simplest controllable design that achieves it?”

Start with five gates:

1. Outcome: name the user and observable job to be completed.
2. Evidence: establish a baseline using the current human, search, script, or workflow process.
3. Variability: locate the part that genuinely benefits from model judgment.
4. Consequence: identify harms from wrong answers, wrong actions, delay, disclosure, or denial of service.
5. Control: prove that identity, permissions, approvals, budgets, evaluation, recovery, and ownership can match the consequence.

If a fixed workflow passes the outcome test, use it. If a model helps only with classification or drafting, keep the rest deterministic. Agentic control is justified only where runtime choice creates measured value that simpler paths do not.

Stopping is a valid product decision. A prototype that reveals the task is unsuitable has produced useful evidence.

Build versus buy is a lifecycle experiment

“Build” and “buy” are rarely binary. You may buy model inference and observability, build the policy layer, and integrate an existing workflow engine. Compare candidate stacks at the component boundary you actually control.

Use the same representative dataset and task contract for each option. Record evidence in these dimensions:

Do not invent ROI. Establish the current cost and quality baseline, run a time-boxed pilot, measure the candidate on the same tasks, and state uncertainty. Price sheets, rate limits, model behavior, and vendor terms can change; attach an as-of date to every comparison.

Popularity is not a control. A widely used framework can still be wrong for your data boundary, deployment environment, or recovery requirement.

Preserve an exit path

Keep business policy, authorization, eval cases, and canonical records outside a supplier-specific prompt. Version adapters. Test export and restore before signing, not only when leaving. Define what happens if a model is retired, a region fails, a price changes, an API response changes, or a supplier blocks an account.

The goal is not zero dependence. It is visible dependence with an affordable, rehearsed response.

Governance is a decision-and-evidence system

A policy PDF does not govern an agent. Governance makes decisions repeatable, records who accepted residual risk, and watches the system as it changes.

For each use case, maintain:

• accountable product and operational owners;
• intended purpose, users, affected people, and prohibited uses;
• system/data flow, suppliers, models, tools, and regions;
• risk and impact assessment proportional to context;
• evaluation plan, limitations, human-oversight design, and accessibility checks;
• security, privacy, retention, incident, complaint, and appeal procedures;
• release history, approvals, exceptions, expiration dates, and monitoring evidence.

NIST AI RMF organizes work as Govern, Map, Measure, Manage. Treat the functions as a continuous loop, not a one-time checklist. As of July 17, 2026, NIST says AI RMF 1.0 is being revised; record the version you use and review the update when published.

A material change may be a new intended use, population, model, tool, data source, autonomy level, region, supplier term, or failure pattern. Define this trigger before launch.

Regulation: classify the use, role, and date

This section is an engineering orientation, not legal advice. Laws depend on jurisdiction, sector, intended purpose, people affected, and whether your organization is a provider, deployer, importer, distributor, employer, controller, processor, or something else. Involve qualified counsel for the actual product.

Do not auto-label every support agent high-risk

Under the EU AI Act, high-risk classification is tied to specific conditions and intended uses in Article 6, Annex I, and Annex III. A support chatbot is not automatically high-risk because it uses an LLM. The analysis changes if the same system is intended to make or materially influence decisions in listed contexts such as employment, education access, essential services, law enforcement, migration, biometrics, or safety components of regulated products.

Document the intended purpose, actual deployment context, inputs, outputs, affected people, decision influence, and exemptions or exclusions considered. Do not ask the model to classify itself. Do not stretch a disclaimer to hide an actual high-consequence use.

Other law still matters: privacy and data protection, consumer protection, anti-discrimination, accessibility, intellectual property, employment, communications, product safety, and sector rules may apply even when an AI Act high-risk category does not.

EU AI Act timeline checked July 17, 2026

The timeline is changing. Record both the legal text and later amendment status:

This is exactly why a course should not freeze “the compliance date” into an undated slide. Add jurisdiction, source URL, retrieval date, reviewer, and next review date to the governance file.

I do: decide the support capstone's boundary

The offline support capstone reads synthetic tickets and knowledge articles, drafts guidance, and can propose—but never execute—a simulated refund. I would approve it as a teaching prototype, not a customer deployment.

My decision record says:

• Purpose: demonstrate bounded triage and an approval-gated simulated proposal. The command-line allowlist is not authenticated, one-use human approval.
• Agentic need: limited; the deterministic model is pedagogical. A real support product must prove model choice improves ambiguous routing over a workflow baseline.
• Data: synthetic only; production tenant identity and customer-data controls are absent.
• Consequence: wrong guidance, disclosure, and financial action are foreseeable.
• Controls present: typed bounded tools, denial by default, simulated proposal, trace, limits, and deterministic tests.
• Controls missing for production: authenticated tenant filtering, durable state/resume, live incident process, supplier review, real privacy workflow, customer appeal, cost ledger, and rollback rehearsal.
• Decision: continue as an offline lab; do not connect it to billing or customer records.

The missing-control list is not paperwork. It preserves the boundary between a useful demonstration and an authorized product.

We do: screen a changed use case

Suppose a manager asks to reuse the support agent to rank job applicants.

Together, work through the evidence:

1. the intended purpose and affected people changed materially;
2. the decision now concerns employment, an Annex III area that requires careful Article 6 analysis;
3. support-ticket evals do not establish validity for applicant ranking;
4. consent language does not cure unfairness, poor validity, or an unlawful use;
5. product approval must be reopened with employment, privacy, security, accessibility, and legal specialists;
6. until that review is complete, tools and data access for the new use remain unavailable.

Notice the wording: requires classification and legal analysis, not “is automatically high-risk.”

You do: LAB-20 — Defend the product decision

Choose Capstone A or B and prepare a governance defense:

1. write the outcome, baseline, non-agent alternative, and evidence for model-chosen control flow;
2. compare build, buy, and hybrid options on the same ten-case eval set;
3. obtain and date supplier evidence for data, retention, training use, regions, subprocessors, versions, quotas, incident terms, export, and deletion;
4. calculate lifecycle cost from measured lab workload, labeling unknowns instead of inventing savings;
5. map owners, affected people, foreseeable harms, controls, residual risks, and appeal paths;
6. perform a jurisdiction/use/role screen, quoting official sources and their retrieval dates;
7. state whether Article 6/Annex III analysis is implicated and why—without making an automatic conclusion;
8. define material-change triggers and an approval expiry date;
9. present the decision in seven minutes, then answer one skeptic from product, security, privacy, operations, and an affected-user perspective.

Done when: a reviewer can reproduce the decision from evidence, distinguish prototype from production approval, and see exactly which fact or change would reopen it.

Pause & Recall

1. What must be true before agentic control is justified?
2. Name four build-versus-buy dimensions that a demo cannot prove.
3. Why is portability tested before purchase?
4. What makes governance continuous?
5. Why is a support agent not automatically an EU high-risk system?
6. Which date and publication checks belong beside a regulation summary?

Production lens

Connect the inventory to deployment controls. An unapproved use case should not obtain production credentials. A lapsed supplier review, changed model, new write tool, new data region, or expired exception should block promotion automatically where feasible. Evidence retention must itself follow privacy and security rules.

Create channels for users and staff to report errors, contest consequential outcomes, request human review, and learn when they are interacting with AI where required. Track whether oversight works: approval quality, override rate, appeal outcomes, unresolved complaints, incident recurrence, and time to disable a harmful capability.

Chapter compression

• Begin with the user outcome, baseline, consequence, and simplest controllable design.
• Compare build and buy using the same workload and lifecycle evidence.
• Governance assigns decisions, owners, evidence, expiry, and change triggers.
• Regulation follows intended use, role, jurisdiction, and current text—not the “agent” label.
• EU high-risk classification is contextual; support automation is not automatically high-risk.
• Date every legal summary and verify publication before relying on a changing timeline.

Memory hook: Prove the need; test the options; govern the change; date the law.

Retrieval deck

• Q: What is the first product question before choosing an agent framework?
  A: Which observable user outcome deserves a system, and what is the simplest controllable way to achieve it?
• Q: How should build and buy options be compared?
  A: Against the same representative workload, task contract, risk controls, lifecycle costs, and exit test.
• Q: What four functions organize NIST AI RMF?
  A: Govern, Map, Measure, and Manage.
• Q: Does an LLM support agent automatically qualify as high-risk under the EU AI Act?
  A: No; classification depends on Article 6 conditions, intended purpose, actual context, and Annex I/III uses.

Spaced review

• Now: explain why “popular” and “enterprise-grade” are not decision evidence.
• +1 day: reconstruct the five product gates without looking.
• +3 days: compare one supplier and one build path using the evidence matrix.
• +7 days: repeat the EU use-case screen with an employment or education scenario.
• +14 days: refresh every dated vendor and regulatory fact in your decision record.

Sources and further study

• NIST AI Risk Management Framework Resource Center
• NIST AI RMF Core—Govern, Map, Measure, Manage
• NIST AI 600-1, Generative Artificial Intelligence Profile (PDF)
• EUR-Lex, Regulation (EU) 2024/1689
• European Commission, AI Act and Application Timeline
• Council of the EU, Artificial Intelligence Timeline
• European Parliament Legislative Observatory, Digital Omnibus on AI